On 14/03/2020 10:08, Oleg Kalnichevski wrote: <snip/>
> I am not really qualified to comment on the proposal but as far as I > can see it makes sense. > > Client side libraries however have an extra problem to contend with. > > Most of the time HttpClient just passes the request URI to server as > is, exactly as specified by the user. > > There is a catch though. Absolute request URIs need to be parsed and > split into respective authority and path/query components. > > http://host:8080/stuff/123 > > --- > GET /stuff/123 HTTP/1.1 > Host: host:8080 > --- > > However there is a fringe case that can cause creation of ambiguous or > illegal request messages. > > What is one supposed to do with absolute request URIs like this one? > > http://host:8080//stuff///123 > > There does not appear to be any statement in the RFC7230 as to what the > expected behavior should be. In discussion with the httpd folks it appears that the consensus view there is that "/a//b/" != "/a/b/" The definitions in RFC 3986 allow a URI of "/a//". For two reasons Tomcat takes a different view: 1. Applications constructing URIs often get it wrong and add an extra "/" where it is not necessary. If Tomcat didn't collapse these, those applications would break. 2. When serving static resources, file systems will collapse "//" to "/". > What we presently do in both 4.x and 5.x release lines is normalizing > such request URIs by collapsing multiple consecutive forward slashes in > the path component into a single one. Tomcat will do that as well for URIs it receives. It could be argued that Tomcat should not do this. If we ever have a user with a use case for not collapsing them then I suspect we'll add an option to make that behaviour optional. > By default HttpClient would generate this request as > --- > GET /stuff/123 HTTP/1.1 > Host: host:8080 > --- > > and not as > --- > GET //stuff///123 HTTP/1.1 > Host: host:8080 > --- > > That should not be relevant as far as this proposal is concerned but I > thought I should mention it just in case as handling of consecutive > forward slashes in the path component of request URIs had caused us a > lot of grief in the past. Thanks. It is useful to see where difficulties have occurred in the past. Tomcat would treat the above 2 requests as the same but I understand that httpd would not. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
