commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Carlson <joncrl...@yahoo.com>
Subject RE: [HttpClient] Post parameters
Date Wed, 05 Jun 2002 15:39:53 GMT
Thanks for the reply, Marc.  

I think that, while the official specification is
important, it is more important to stick with the defacto
spec (or at least offer an option to use defacto spec
behavior).

Given that neither Netscape, Mozilla, nor IE follow the
spec (that is, passing params to the redirected URL), and
because most sites specifically state that they support one
of these browsers and no others, there will be a lot of web
sites out there that depend on that behavior.  

For example, the application that I am trying to monitor
uses the redirect to say "I'm done processing, now view
this other page", rather than to say "You really should
have gone here in the first place".  I think a lot of
applications out there were built that way (especially JSP
applications) because it worked on IE and Netscape.  At
this point in the game, I would be very surprised if IE and
Netscape ever did implement the spec correctly because they
would be keeping their customers from using many sites and
hence, would lose market share.  

Also, if anything would implement the spec correctly,
Mozilla would, and the app I'm monitoring works fine with
Mozilla.

I can try my hand at internally creating a GetMethod on
redirect, but I don't have a lot of confidence that I will
consider everything that probably should be considered.  I
support your idea of creating a new GetMethod for
redirects.  It's a much more O-O way to go and it could
help clean up the HttpMethodBase#execute method too.  

I would probably also argue that when spec-compliant
behavior is needed, creating a new PostMethod for the
redirect would be better too.  The simplification and
improved maintainability of the code would more than offset
the minor overhead from creation of another instance.  Even
if, in some probably rare case, it becomes a performance
problem then an internal pool of PostMethods can be used.

Thanks, let me know how to proceed or whether I should wait
for someone else to change it.

Jonathan


--- Marc.Saegesser@apropos.com wrote:
> [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>
> 


=====
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>


Mime
View raw message