I wish I'd done a bit more digging before my original post. It turns out the problem is that parameters were being encoded *twice*. We were encoding them once on our own, then the URI constructor was encoding them again. My "Mountain View" example was being encoded as "Mountain%2520View". If we encode them only once (even with %20 rather than +) everything works.
Good I'm glad that's working now.
>... are we correctly handling query params by URI encoding them?
Probably not. HTTP 4.01 <http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4.1> says:
application/x-www-form-urlencodedSection 4 says "must" means MUST in the rfc2119 sense, so I think we have to do URL encoding rather than URI encoding for the query parameters. A quick replacement of ' ' with '+' followed by the usual URI encoding might do it.
This is the default content type. Forms submitted with this content type must be encoded as follows:
1. Control names and values are escaped. Space characters are replaced by `+', and then reserved characters are escaped as described in [RFC1738] <http://www.w3.org/TR/html4/references.html#ref-RFC1738>, section 2.2: Non-alphanumeric characters are replaced by `%HH', a percent sign and two hexadecimal digits representing the ASCII code of the character. Line breaks are represented as "CR LF" pairs (i.e., `%0D%0A').
Yes, but this is for application/x-www-form-urlencoded values. Currently we only assume this content type for post params (this was recently fixed). Standard query params are using the URI encoding. The confusing part is that it's possible to submit a form via a GET. In this case the params are passed in the query. In this case should application/x-www-form-urlencoded be used?
Mike
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
