On 07/01/2020 16:22, Christopher Schultz wrote: <snip/>
> Since the Host header seems to be special in this regard (i.e. there > is no prohibition against multiple Accept headers), might we be > willing to interpret the spec in a slightly less strict manner? > > " > A server MUST respond with a 400 (Bad Request) status code to any > HTTP/1.1 request message that lacks a Host header field and to any > request message that contains more than one Host header field [[WITH A > CONFLICTING VALUE]]] or a Host header field with an invalid field-value. > " > > So a request with: > > Host: foo.bar.com > Host: foo.bar.com > > Would be okay, while: > > Host: foo.bar.com > Host: bar.foo.com > > Would return a 400 response? Not sure. The usual concern with multiple headers is that a reverse proxy uses one, the back-end uses another and you get unexpected behaviour that may result in some sort of information leak - i.e. a vulnerability. That shouldn't apply here since the values are the same. Experience suggests that being more relaxed about parsing an HTTP request that the specification requires is likely to result - at some point in the future - with a vulnerability report. In this instance I can image some other server somehow merging the two header values and - essentially - treating it as a different value to Tomcat. That could lead to a similar information disclosure as above. The usual counter argument is that there is no vulnerability if the other server is spec compliant. But the same is true if Tomcat is spec compliant. I certainly wouldn't support this behaviour by default. Making the behaviour configurable is possible so it could be enabled when necessary and safe to do so (i.e. clients connecting directly to Tomcat). That then gets you to the question how complex would this be to implement and is that complexity justified by the benefit it brings? At this point, I'm not sure. So far we are looking at a feature required by a single user to handle clearly non-spec compliant clients. I lean more towards a custom protocol / processor implementation when a single user is affected. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
