Redirect and Tomcat

[Roman Shpak]

How can I resolve problem such as redirect from one url to another help
with tomcat same as option "Redirect" in Apache?

[Filip Hanik]

not really sure what you are asking,
but
response.sendRedirect(...) in HttpServletResponse

will do that


-----Original Message-----
From: Roman Shpak [mailto:***@cg.ukrtel.net]
Sent: Wednesday, January 29, 2003 3:41 PM
To: tomcat-***@jakarta.apache.org
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: tomcat-user-***@jakarta.apache.org
For additional commands, e-mail: tomcat-user-***@jakarta.apache.org

[Roman Shpak]

Post by 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.

[Paul Yunusov]

Post by Roman Shpak

Post by 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

[Erik Price]

Post by Paul Yunusov
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

[Daniel Brown]

This was news to me too. But, from the horse's mouth:

RFC 2616 HTTP/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.

Post by Filip Hanik
-----Original Message-----
Sent: 30 January 2003 16:01
To: Tomcat Users List
Subject: Re: Redirect and Tomcat

Post by Paul Yunusov
Roman,
The HTTP1.1 spec says the client should follow the redirect

only if the method

Post by Paul Yunusov
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
---------------------------------------------------------------------

[Erik Price]

[...]

Post by Daniel Brown
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

[Paul Yunusov]

Post by Erik Price
[...]

Post by Daniel Brown
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

[Jon Eaves]

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

Post by Daniel Brown
RFC 2616 HTTP/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 ]