Marc, Thanks for the suggestion. I'll use the <groovy> call along with an <invoke> step to get back to the page I was expecting.
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 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html), 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 issued. 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! Craig > Hi Craig, > > I've checked and htmlunit sets correctly form fields named "method". > > Therefore I guess that you're right and that it has to do with the 302 > that htmlunit skips. I suppose that you get a warning like: > Got a redirect but the location is the same as the page we just loaded > [...]. Skipping redirection. > > As workaround as long htmlunit is not more tolerant, you can use: > <groovy> > step.context.webClient.throwExceptionOnFailingStatusCode = false > </groovy> > <yourstep> > <groovy description="set it back"> > step.context.webClient.throwExceptionOnFailingStatusCode = true > </groovy> > > or if you need it through the whole script as option in the config: > <config ...> > <option name="ThrowExceptionOnFailingStatusCode" value="false"/> > </groovy> > > </config> > > Marc. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ WebTest mailing list [email protected] http://lists.canoo.com/mailman/listinfo/webtest
