> The reason relative URLs should not be allowed is that the HTTP spec says that the
>redirected location must be an absolute URL (For HTTP/1.0, see RFC #1945, Section
> 10.11; For HTTP/1.1, see RFC #2068, Section 14.30).. The fact that some servlet
>engines do not enforce the restriction, and that some client browsers in fact perform
> the expected behavior (they tack the original protocol, host, and port back onto the
>front to recreate an absolute URL) is not something you can count on in the future,
> unless the HTTP spec is changed.
Right -- this is the exact reason why the API has the restriction. To
perform a correct redirect within the api as it stands, get the absolute
URL of this request from HttpUtils, munge that to make your string and
send that to the sendRedirect call.
Now, it is nice for the programmer when an engine will take a relative
url -- and it has been suggested that the spec be changed to do so. If
we go this direction, the sendRedirect call would be required to create
an absolute URL from the partial URL given and emit that to the client
so that the HTTP spec is fully complied with on the wire.
Note that this isn't a committed direction, only a likely one.. :) In
the meantime, for the servlet engine implementors that want to be nice
to your programmers, be sure to emit the full URL when you do the
sendRedirect.
.duncan
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
