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 --- [EMAIL PROTECTED] 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:[EMAIL PROTECTED]] > > Sent: Monday, June 03, 2002 4:17 PM > > To: [EMAIL PROTECTED] > > 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 > > [EMAIL PROTECTED] > > Minneapolis, Minnesota > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! - Official partner of 2002 FIFA World Cup > > http://fifaworldcup.yahoo.com > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > ===== Jonathan Carlson [EMAIL PROTECTED] Minneapolis, Minnesota __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
