tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: not able to access URL in 2nd app in 7.0.23
Date Thu, 26 Jan 2012 09:27:55 GMT
On 26/01/2012 03:59, wrote:
>> When Tomcat receives an unauthenticated request for a protected
>> resource it intercepts and saves that request, then forwards to
>> the resource defined in the login config.
> True.  Also, I'm not making the request through Firefox.  I did that
> below as part of my debugging only.
> I have a Java application.  It calls
> HttpsURLConnection.setFollowRedirects(false);
> At some point it calls
> HttpsURLConnection connection = (HttpsURLConnection)
> url.openConnection();
> where url is "https://localhost:6143/myapp/folder/".  Then
> there is a call to
> connection.setRequestMethod("POST");
> along with the other usual methods for a post request.
> T server intercepts this message and internally directs to
> /login.html.  Either a servlet should build this page or it should
> exist.  However, in 7.0.22 a POST request is made to this page,
> whereas in 7.0.23 a GET request is made.  Is this a bug in tomcat, a
> feature in tomcat, or required by the spec?

This is a design decision. The method used to request the login page
should always be GET regardless of what method was used to access the
protected page. This wasn't always the case and was corrected as part of
the fix for [1] in [2].

> Then the login.html page is generated and sent back to the client.
> The client will then read this message and verify it is the expected
> login page.  The client will then send a post request to
> https://localhost:6143/myapp/j_security_check providing the username
> and password.

Whether POST or GET is used here will depend on the login page since it
is defined by the method attribute of the form element.

> At this point the server will authenticate, and if valid, will send
> 302 (redirect) with the URL as the page that was originally
> requested.
> The Java client should now repeat the original post request.

The method to be used at this point is unclear to say the least. See
RFC2616 and the discussion on the handling of 302 redirects. Ideally,
this should be treated as a 303 redirect and a GET request issued.
Repeating the POST needlessly sends the request body again which Tomcat
will just silently swallow as it will restore the request body from the
original request.

Using a 303 in this case is under consideration for the next version of
the servlet spec.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message