https://bz.apache.org/bugzilla/show_bug.cgi?id=62150
--- Comment #5 from Mark Thomas <ma...@apache.org> ---
Indeed. The behaviour of getRequestURI() is at the root of this bug report and
bug 61185.
In terms of guidance from the spec, what we have is:
- getRequestURI() Returns the part of this request's URL from the protocol name
up to the query string in the first line of the HTTP request. The web container
does not decode this String.
- For forward(), the path elements of the request object exposed to the target
servlet must reflect the path used to obtain the RequestDispatcher.
The implication that the value returned by getRequestURI() is unencoded is that
it is also not normalized. This is because, for untrusted URIs, you have to
decode first to ensure any encoded '.' or '/' characters are correctly handled.
Note that for a RequestDispatcher we have a little more leeway because the
paths are trusted.
Bug 61185 was, essentially, that if an encoded path was used to obtain a
RequestDispatcher then when getRequestURI() was called it should return that
original, encoded path.
By extension, if a non-normalized absolute path is used to obtain a request
dispatcher then the expectation is that, for a forward(), getRequestURI()
should return that original, non-normalized path.
Where things get tricky is when a RequestDispatcher is obtained via a relative
path. Which path should the relative path be resolved against (original or
decoded + normalized) and should the path be normalized after it has been made
absolute?
Maybe some examples will help:
Original RD Path URI after forward()
/aaa/bbb zzz /aaa/zzz
/aaa/../bbb zzz /zzz
/aaa/../zzz
/aaa/bbb ../zzz /zzz
/aaa/../zzz
/aaa/bbb/../ccc zzz/xxx/../yyy /aaa/bbb/../zzz/xxx/../yyy
/aaa/zzz/xxx/../yyy
/aaa/zzz/yyy
Looking at these I'm leaning towards the current behaviour as being closest to
the intention of the spec but I confess that is a purely subjective judgement.
Feedback and further thoughts on the above welcome.
If we do want to normalize something here, I do think the proposed patch isn't
quite right as a RequestDispatcher obtained with a non-normalized path would
not then return that non-normalized path for getRequestURI() after a forward.
If we go this route I think the normalization would need to be earlier.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
