Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Submitted By: craig (craig_copeland)
>Assigned to: Marc Guillemot (mguillem)
>Summary: 302 Redirection to the same url after a POST not followed
HtmlUnit is not following the 302 response in
particular situations. This seems to be exactly what
davidmhill was trying to describe in bug:
https://sourceforge.net/tracker/index.php?func=detail&aid=1359254&group_id=47038&atid=448267 1. Looking at the HTTP headers in AID 1359254, you see
a POST to URL x, and a 302 response with Location x.
2. There may also be a strict enforcement of RFC 2068
that is superceding a relevant Note in RFC 2616.
Please, see the email below for more info on this.
In the meantime I will attempt to find a simple
reproduction scenario if needed. Please contact me if
this is needed.
perhaps could you open an issue / add this comment to
an existing one by htmlunit?
Craig Copeland wrote:
> I think this issue is likely two fold.
> 1. The Location returned in the 302 is identical to
> the original submitted. This could potentially cause
> an inifite loop. The user-agent could allow for a
> finite number of redirects to the same location.
> The software I'm testing uses other fields to know
> if a 302 should be issued after a POST, which would
> keep the infinite loop from occurring.
> 2. It could also be that since HtmlUnit is a very
> strict user-agent implementation, that section
> 10.3.3 of RFC 2616 (concerning 302 responses) is
> being enforced in respect to how to treat a 302
> redirect if the inital method was POST instead of
> GET (or HEAD). However, looking at the full context
> of RFC 2616,
> it says:
> If the 302 status code is received in response to
> a request other than GET or HEAD, the user agent
> MUST NOT automatically redirect the request unless
> it can be confirmed by the user, since this might
> change the conditions under which the request was
> Note: RFC 1945 and RFC 2068 specify that the
> client is not allowed to change the method on
> the redirected request. However, most
> existing user agent implementations treat 302
> as if it were a 303 response, performing a
> GET on the Location field-value regardless
> of the original request method. The status
> codes 303 and 307 have been added for servers
> that wish to make unambiguously clear which
> kind of reaction is expected of the client.
> HtmlUnit may be strictly enforcing 1945 & 2068, and
> disregarding the Note above.
> Again, thanks!
>Comment By: Marc Guillemot (mguillem)
Date: 2006-09-20 21:33
Logged In: YES
Now fixed in SVN: htmlunit tries to react like browsers
rather than like the RFC.
Thanks for writing this test... even if I couldn't use it.
You may want to have a look at
to see how the unit test looks like.
2. Run the perl httpdebug script to mimic a web server. Use
attached perl script and name file httpdebug.pl.
Suggested runtime call:
> perl httpdebug.pl -p 8888
This will start a webserver listening on port 8888.
(Code taken mostly from:
3. To see a redirect work correctly open IE and:
a. enter this URL address
b. Click the Submit button
===> The command shell where you started the perl script
should print out a line each time the redirect (302) and the
normal (200) pages are returned to your browser.
4. After tweaking the script appropriately, run the attached
Canoo WebTest script:
>webtest -buildfile test.xml
oo Webtest: R_1375.
Test step clickButton (C:\Documents and
\tests\test.xml:24: ) failed with message "Step[clickButton
(3/4)]: HTTP error
302, at: clickButton"