On 26/01/2012 03:59, removeps-c...@yahoo.com 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/action.do";. 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. Mark [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=51940 [2] http://svn.apache.org/viewvc?view=revision&revision=1181030 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
