On 07/01/2020 07:10, Dennis Rech wrote: > POST /foo HTTP/1.1 > Host: foo.com > POST /foo HTTP/1.1 > Host: foo.com > Content-[stuff] [...]
First two lines are OK. The third line is going to be treated as an HTTP header. It is invalid and Tomcat will reject it with a 400 response but you can tell Tomcat to just ignore the invalid header with rejectIllegalHeaderName="false" on the Connector. The problem is going to be the second Host header. RFC 7230 states: <quote> 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 or a Host header field with an invalid field-value. </quote> Any spec compliant server is almost certainly going to reject that request. I guess a server might provide a hook for request modification prior to rejection to allow the "fixing" of known invalid requests but I'm not aware of any that do - at least not without going down the writing a custom module route. If we made Http11Processor.prepareRequest() protected then it would be fairly simple to write a custom Processor that: - extended Http11Processor - overrode prepareRequest() to a) remove the duplicate Host header b) call super.prepareRequest() I could provide one for you if you weren't comfortable doing that yourself). However, even if we made the change now (which I'm happy to do if you think it would be useful) it will take a while to filter through to the Debian distribution. There are several variations on this theme. One could write a custom Processor for 8.5.50 that did the same thing - it would just be rather more involved as one would have to copy rather more code from Http11Processor. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
