RE: Redirect and Tomcat
This was news to me too. But, from the horse's mouth: RFC 2616HTTP/1.1 June 1999 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. So, in theory, you should generate a 303 response if the request method was POST, and the web page you're redirecting to should be retrieved with a GET. But in practice, the web browser will do just what you expect it to do if a 302 response is received. Dan. -Original Message- From: Erik Price [mailto:[EMAIL PROTECTED]] Sent: 30 January 2003 16:01 To: Tomcat Users List Subject: Re: Redirect and Tomcat Paul Yunusov wrote: Roman, The HTTP1.1 spec says the client should follow the redirect only if the method is GET or HEAD, so check that. Pardon for butting in, but does this mean that my login servlet which accepts and processes a POST request, then uses response.sendRedirect() to send the user to a different resource (another servlet), is invalid? Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirect and Tomcat
Daniel Brown wrote: This was news to me too. But, from the horse's mouth: [...] So, in theory, you should generate a 303 response if the request method was POST, and the web page you're redirecting to should be retrieved with a GET. But in practice, the web browser will do just what you expect it to do if a 302 response is received. Hm... yes, in practice it works (currently that is how my app handles logins and it works in all browsers AFAIK), but at some point someone might implement the spec. I always try to write in compliance of the spec, so what I'm wondering is how I can specify that the sendRedirect should use GET instead of the original method, which was POST. (I seem to recall reading somewhere that sendRedirect uses the original method.) Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirect and Tomcat
On Thursday 30 January 2003 11:34 am, Erik Price wrote: Daniel Brown wrote: This was news to me too. But, from the horse's mouth: [...] So, in theory, you should generate a 303 response if the request method was POST, and the web page you're redirecting to should be retrieved with a GET. But in practice, the web browser will do just what you expect it to do if a 302 response is received. Hm... yes, in practice it works (currently that is how my app handles logins and it works in all browsers AFAIK), but at some point someone might implement the spec. I always try to write in compliance of the spec, so what I'm wondering is how I can specify that the sendRedirect should use GET instead of the original method, which was POST. (I seem to recall reading somewhere that sendRedirect uses the original method.) Erik Section 10.3.4 of RFC 2616 (HTTP/1.1) addresses your problem: quote 10.3.4 303 See Other The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable. The different URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303. /quote Again, setStatus() and sendRedirect() in HttpServletRequest are your friends here. I pulled the information above from rfc-editor.org. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirect and Tomcat
Hi all, And just to follow up on that, you should always serve your login page under SSL as otherwise the bad guys can change the FORM action parameter and use it to grab your usernames and passwords. So, the initial GET to grab the login page can trigger the http-https redirect rather than doing it under the POST of the FORM. Which is the best course of action anyway. Cheers, -- jon Daniel Brown wrote: This was news to me too. But, from the horse's mouth: RFC 2616HTTP/1.1 June 1999 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. [ snip ] -- Jon Eaves [EMAIL PROTECTED] http://www.eaves.org/jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Redirect and Tomcat
not really sure what you are asking, but response.sendRedirect(...) in HttpServletResponse will do that -Original Message- From: Roman Shpak [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 29, 2003 3:41 PM To: [EMAIL PROTECTED] Subject: Redirect and Tomcat How can I resolve problem such as redirect from one url to another help with tomcat same as option Redirect in Apache? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirect and Tomcat
30 ñÎ×ÁÒØ 2003 01:49, Filip Hanik ÎÁÐÉÓÁÌ: not really sure what you are asking, but response.sendRedirect(...) in HttpServletResponse will do that Yes, of course, I know it. But problem is in redirect one url to another without any program code in servlet or jsp. Why? It needs for forward all request from https://www to https://... so if try to do this with response.sendRedirect(...) catchs warning box. But if using Apache which has directive redirect in conf file warning box never shows. So has Tomcat similar directive? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirect and Tomcat
On Wednesday 29 January 2003 07:52 pm, Roman Shpak wrote: 30 ñÎ×ÁÒØ 2003 01:49, Filip Hanik ÎÁÐÉÓÁÌ: not really sure what you are asking, but response.sendRedirect(...) in HttpServletResponse will do that Yes, of course, I know it. But problem is in redirect one url to another without any program code in servlet or jsp. Why? It needs for forward all request from https://www to https://... so if try to do this with response.sendRedirect(...) catchs warning box. But if using Apache which has directive redirect in conf file warning box never shows. So has Tomcat similar directive? Thanks. Roman, The HTTP1.1 spec says the client should follow the redirect only if the method is GET or HEAD, so check that. Also, check the status code for the response. Apache 1.3.27 uses HTTP status 302 with its Redirect directive by default. It's not clear what status Tomcat uses for sendRedirect() from the servlet specs, which only say Sends a temporary redirect response to the client using the specified redirect location URL. You can try different 3xx status codes using setStatus() from HttpServletResponse. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
