commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc.Saeges...@apropos.com
Subject RE: [HttpClient] Post parameters
Date Tue, 04 Jun 2002 19:13:23 GMT
[NOTE:  I've been away from the HttpClient stuff for a while due to other
priorities with the DDJ and other duties (like trying to keep three small
airplanes flying when all they want to do is break down).  I'm slowly
pulling myself back from the abyss and I hope to become more active in this
stuff again soon].

The response to a 302 redirect of a POST method is *SUPPOSED* to contain all
the original data (query string, request body).  The 302 redirect tells the
client that requested resource is now available at a different (possibly
temporary) URI.  The client should therefore resend the original request to
the new URI provided in the 302 responses Location header.  The client is
also required to ASK THE USER FOR PERMISSION before redirecting a POST
request.  This is because the user may not want to send the data to the new
URI (it might be to a different host, use different security, etc.).

Now, having said all that, most browsers *DO THIS WRONG*.  When they receive
a 302 response for *any* method they always send a GET to the new URI,
instead of resending the original request.  This is spelled out quitely
clearly in RFC 2616 (section 10.3.3).  It has been this way from the
begining; the browser developers just got it wrong and haven't fixed it yet.
What is truly horrible, though, is that there are some server applications
out there that *require* this broken client behavior.  The Yahoo! login
process is my favorite whipping boy for this, but there are others.

The architecture of HttpClient/HttpMultiClient makes it very difficult to
implement the broken behavior because it can't change a POST into a GET.  It
is passed a class of type GetMethod or PostMethod (or UrlGetMethod or
UrlPostMethod) and it can't change the type of the class it got.  The best
idea I've had so far is to create a new GetMethod class internally, send
that request and then copy the response data from the temporary GET method
back into the original POST method got in the first place.  If anyone has
any better ideas I'd love to hear them.

Marc Saegesser 

> -----Original Message-----
> From: Jonathan Carlson [mailto:joncrlsn2@yahoo.com]
> Sent: Monday, June 03, 2002 4:17 PM
> To: commons-dev@jakarta.apache.org
> Subject: [HttpClient] Post parameters
> 
> 
> After experienced undesired behavior and looking at the
> code it appears that POST parameters are also being passed
> to the redirected page.
> 
> I've tried fixing this with a little tweak, but I am
> realizing that it may be more involved than I had
> originally thought.
> 
> Has anyone else experienced this?  I'm using the 5/28
> nightly build.
> 
> Jonathan
> 
> =====
> Jonathan Carlson
> joncrlsn@users.sf.net
> Minneapolis, Minnesota
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
> 
> --
> To unsubscribe, e-mail:   
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <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