> On Fri, 13 Apr 2001, Klaus Sonnenleiter wrote:
>
> > Craig,
> >
> > I looked at HttpRequestImpl. Would it be safe to manipulate the URI in a
> > call to setRequestURI before it sets the instance variable requestURI?
It
> > seems like this gets called the moment a request is made - this way, the
> > encoded characters could be transformed to their unencoded equivalents
> > before the parameter list is parsed and the classloader gets called.
> >
> > Klaus
> >
>
> The key thing to remember is a spec requirement that
> request.getRequestURI() must return the original request URI *without*
> decoding. The values returned by request.getServletPath() and
> request.getPathInfo(), on the other hand, are decoded first. Therefore,
> if you manipulate the request URI value in setRequestURI(), we'd need to
> make sure that we save an unmanipulated version somewhere as well.
>
> The deeper issue, though, is the portability of what you are
> proposing (across servlet containers) would be. As I understand it, you
> would like the %3f character to be interpreted as a "?" character so that
> the stuff after it is understood as part of the query string. That seems
> (to me) a questionable practice -- the reason you would use a %3f encoding
> in the first place is so that you could treat a question mark as a regular
> data character, instead of being a significant delimiter. If you decode
> first and then find that the "?" is significant, how would you ever
> include a question mark as part of the data value for a query string
> parameter (for example)?
>
> NOTE: There also needs to be a little more work in this area with respect
> to path parameters (;xxx stuff, which is how the session id is
> transmitted). This is being discussed in the expert group, and will
> probably require some minor changes in this area of Tomcat 4.
'?' shouldn't be encoded in the first place as it's a reserved character
(just like you should never encode '/' in the path). If it's encoded, I
don't think it should be interpreted as the delimiter for the query section
of the URL.
So IMO the current TC behavior is the right one.
The RFC for URIs is http://www.ietf.org/rfc/rfc2396.txt
Remy
