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