commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Hyatt <ahy...@intraspect.com>
Subject Re: [HttpClient] URI request fix and multiple method fix
Date Mon, 23 Sep 2002 19:28:28 GMT

"Jeff Dever" <jdever1@nortelnetworks.com> writes:

> Hey Andrew, 
> 
> Thanks for your comments.  I definately agree with you regarding the
> call to endSession() inside startSession().  Regarding the path
> encoding, I'm not as sure.  If the client was trying to refrence a web
> page that lived in a directory with a space in it (evil, yes), the space
> does need to be encoded.  Is there a case where the current encoding is
> causing problems?

Yes, the current encoding definitely causes problems.  Right now,
normal servlets do not expend encoded arguments.  Let's say I type
into my browser "http://test/testservlet?foo=bar&baz=schmoo

Now, what happens is that when req.getParameter inside
my servlet (req is HttpServletRequest) with argument "foo", I get
"bar", as expected.

However, if the requestor was HttpClient, the URI is encoded, so the
actual URI is ?foo=bar%26baz=schmoo (may not be actual, I'm just doing
this from memory, but you see what I mean).  req.getParameter with
argument "foo" will now return "bar%26baz=schmoo".  This is
incorrect, and it was exactly the error I was seeing when using
HTTPClient against my Tomcat servlet.

> 
> We do appriciate your diffs, but the prefered diff format is unidiff
> (diff -u) which is easier to read as it provides more context.  Also it
> is prefered that patches include JUnit test cases where possible.
> Partiularly with the encoding, a test case that would fail with the
> current code but passes after the patch is applied would be brilliant.

Thanks for the suggestions.  I'll work on a JUnit test case and get
back to you.  Or should I submit the patch for the test case to the
developer forum?

> 
> There is more information on contributing to Jakarta-Commons: 
> http://jakarta.apache.org/commons/patches.html
> <http://jakarta.apache.org/commons/patches.html>  
> 
> -jsd 
> 
> 
> > -----Original Message----- 
> > From: Andrew Hyatt [ mailto:ahyatt@intraspect.com
> <mailto:ahyatt@intraspect.com> ] 
> > Sent: Thursday, September 19, 2002 12:23 PM 
> > To: commons-dev@jakarta.apache.org 
> > Subject: [HttpClient] URI request fix and multiple method fix 
> > 
> > 
> > 
> > There are two bugs in HttpClient I've noticed.  One is the simple 
> > matter that the HTTP request is escaped.  It should not be.  The 
> > fix for this: 
> > 
> > Index: HttpMethodBase.java 
> > =================================================================== 
> > RCS file: 
> > /home/cvspublic/jakarta-commons/httpclient/src/java/org/apache 
> > /commons/httpclient/HttpMethodBase.java,v 
> > retrieving revision 1.55 
> > diff -r1.55 HttpMethodBase.java 
> > 1205,1206c1205 
> > <         buf.append((null == reqPath) 
> > <                    ? "/" : URIUtil.encode(reqPath, 
> > URIUtil.pathSafe())); 
> > --- 
> > >         buf.append(null == reqPath ? "/" : reqPath); 
> > 
> > The next is that you cannot execute two methods in a row (to the same 
> > url, with different parameters, say), instead you had to close 
> > and create a new HttpClient.  THe solution is simple, we just have to 
> > make sure our session is closed before we open a new one.  The 
> > patch is: 
> > 
> > Index: HttpClient.java 
> > =================================================================== 
> > RCS file: 
> > /home/cvspublic/jakarta-commons/httpclient/src/java/org/apache 
> > /commons/httpclient/HttpClient.java,v 
> > retrieving revision 1.54 
> > diff -r1.54 HttpClient.java 
> > 192c192 
> > < 
> > --- 
> > >         
> > 196a197,204 
> > >         
> > >         // Stop the old session before creating a new one 
> > >         try { 
> > >             endSession(); 
> > >         } catch (IOException e) { 
> > >             log.error("HttpClient.startSession: error 
> > closing the old session before starting the new one"); 
> > >         } 
> > > 
> > 
> > 
> > BTW, for some reason I cannot subscribe to any of the jakarta lists. 
> > So if you want to communicate with me, it would be most reliable to 
> > mail me back at this address. 
> > 
> > 
> > 
> > 
> > -- 
> > To unsubscribe, e-mail:   
> > < mailto:commons-dev-unsubscribe@jakarta.apache.org
> <mailto:commons-dev-unsubscribe@jakarta.apache.org> > 
> > For additional commands, e-mail: 
> > < mailto:commons-dev-help@jakarta.apache.org
> <mailto:commons-dev-help@jakarta.apache.org> > 
> > 
> > 


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message