[gdal-dev] WFS driver does not do URL-encoding right

Jukka Rahkonen jukka.rahkonen at mmmtike.fi
Thu Aug 16 01:37:55 PDT 2012


I think this is my last question about WFS and URL-encoding this time.

I had a look how the WFS requests look in hexadecimals.

My TinyOWS and Mapserver WFS both accepts two ways to express letter "ä" inside
ogc:Filter with http GET. First of those alternatives is an UTF-8 letter "ä" in
URL-encoded format which looks as text like %C3%A4. Corresponding hex values in
the GetFeature request seem to be 25-43-33-25-41-34. Another alternative that
works also it to give letter "ä" in UTF-8 without URL-encoding it and then the
hex values are C3-A4.

My question is that are both alternatives correct to use in http GET? I have
thought that URLs should use URL-encoding. OGR WFS driver is itself doing URL
encoding for <,>," and [space]. Could it be so that expressing "ä" as plain
C3-A4 in a filter works only because the http GET route is passing them on as
raw, and WFS server by accident interprets them back to "ä" because it is
internally using UTF-8?

There seem to be more to puzzle ordinary people like me. What looks like
character "ä" to me is also an extended ASCII character #228 and some
URL-encoders are translating it to %E4 (probably the reason for gvSIG WFS filter
error).
http://www.blooberry.com/indexdot/html/topics/urlencoding.htm
Some others are considering "ä" as a two-byte UTF-8 character and URL-encode 
that into %C3%A4 
http://www.w3schools.com/tags/ref_urlencode.asp

It must be funny to be a coder.

-Jukka-



More information about the gdal-dev mailing list