Mark, maybe this getting offtopic.
> Am 07.01.2020 um 18:58 schrieb Mark Thomas <ma...@apache.org>: > > 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. > I didn’t think that far! However, if they are the same and tomcat would also have to respond to the given host, that would be extremely unlikely... > 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. > Agreed. > 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? > Just thinking how to handle “n” Host headers at various locations in the request... 8-0 > 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. > That’s true. Could this be a documented “extra”? Like a drop-in Jar? Peter > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
