hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Becke <be...@u.washington.edu>
Subject Re: URI query escapes
Date Fri, 20 Jun 2003 20:28:31 GMT
Hi Laura,

This is something that Oleg and I were discussing recently in regard to 
post parameters being form urlencoded.  This case is partially related.

It seems the server in question is assuming that query params are form 
urlencoded.  The method you are using is actually URI encoding 
everything.  According to URI(rfc 2396) both space and + are encoded as 
their hex values in the query.

The quick solution for this is to not encode the URIs using 
httpclient.URI.  This can be accomplished in two ways:

  - use the XXMethod(String) constructor.  it assumes everything is 
encoded already
  - use XXMethod.setQueryString(String).  it also assumes the query is 
already encoded

Both of these require you to encode the URI before passing it to the 
HttpMethods.

So the next question is... are we correctly handling query params by URI 
encoding them?  I believe that this is generally okay, but as you have 
discovered, it may not work in all cases.  In the server you are hitting 
HTTP 1.0?

Mike

Laura Werner wrote:
> Hi all,
> 
> I'm having a weird problem with escaped characters in the query part of 
> a URI.  In the old, alpha1 version of HttpClient, we used 
> URIUtil.encodeAll() to encode our query parameter values, and it escaped 
> spaces with "+", resulting in "Mountain+View". With the latest 
> HttpClient, we use URIUtil.encodeWithinQuery().  If we encode a query 
> like "Mountain View", we get back "Mountain%20View".
> Does anyone know why this behavior changed?  Our app server is barfing 
> on it for some reason and giving the JSP the encoded string with the %20 
> in it when it calls getParameter.  (This is probably a bug in the 
> server, but our applications group is on my case because the behavior of 
> our client changed.)
> 
> The background ere is that for legacy reasons, we build up the query 
> part of the URL ourselves, encoding each parameter as we append it to 
> the string.  Then we create a java.net.URL object out of it (yuck).  
> Finally, at fetch time, we do new URI(url.toString()).  (Double yuck.)
> 
> I'm going to play with this a bit more.  It may be that I don't even 
> have to encode the query strings myself, and that the new URI 
> constructor will do it for me.  But I figured I'd ask here and see if 
> anyone knew what had changed or had run into a problem like this before.
> 
> Laura Werner
> BeVocal
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: 
> commons-httpclient-dev-help@jakarta.apache.org
> 


Mime
View raw message