https://bz.apache.org/bugzilla/show_bug.cgi?id=62273

--- Comment #12 from Mark Thomas <ma...@apache.org> ---
That wasn't my reading but it isn't the easiest spec to read. It is much closer
to an implementation description than a spec.

I decided to do some testing to see what the current behaviour is. Results
here:
https://cwiki.apache.org/confluence/display/TOMCAT/Encoding+and+URIs

It looks like tightening up the path parsing to limit '[' and ']' would cause
problems. I don't see where the whatwg.org spec allows this though.

I didn't see the automatic conversion of '\' to '/' when I read the spec
either.

The query string behaviour is close to what I expected although IE is worse.

The authority part of the whatwg.org spec is very relaxed for the userinfo
compared to RFC 7230 / RFC 3986 but since Tomcat just ignores the userinfo I'm
not too concerned about that.

Sigh.

I'm still thinking about the best way to approach this. If we have configurable
parser instances they are going to have to be per connector as the URI is
parsed before it can be mapped. I'm wondering if it is worth it. Different
settings per connector is likely to be unusual but on the other hand it isn't
that hard to implement.

One advantage of validating each part separately is that the query string may
have to allow some characters we really don't want in the path like '\'.

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

Reply via email to