Dear Mark,

thanks a lot for your effort and your feedback.


Am 07.01.20 um 10:36 schrieb Mark Thomas:
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.

I already tried the connector option in server.xml and also saw in the documentation the

rejectIllegalHeaderName

option should be on "false" even as default.

The problem is going to be the second Host header.
The second "Host" part is still a problem, you're right.

We have just tried putting nginx as a proxy before the tomcat8 instance and it has intercepted the malformed request fine at least it has not rejected the request with HTTP response code 400.


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.

We will see if the nginx workaround is sufficient :-). Otherwise we will take into consideration your suggestion.

Thanks again.

Dennis


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

Reply via email to