Chris (and Mark),
> Am 07.01.2020 um 17:22 schrieb Christopher Schultz
> <ch...@christopherschultz.net>:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Mark,
>
>> On 1/7/20 4:36 AM, Mark Thomas wrote:
>>> 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.
>
> 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.
> "
That would be a good idea - maybe only in conjunction with setting
rejectIllegalHeaderName=false
If that makes the implementation easier???
>
> 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?
>
That would be a messed up request and worth a 400!
Peter
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4UsEEACgkQHPApP6U8
> pFjprxAAi60mVwH+LHo2HSCl+hwIhIyG2B9Dg2LjIJ8JPMA/WxaiDOOJCS+yMTbV
> rVfdPrlT0B6Zd8ceTjz4ooZa79SwPFfCiFM97q1H/JwwsqVxaBEFEx6PgvnJzUUF
> ZuJJEtQHijQgZo0gXv2plkqHTBrG5NMPNqQYEJ8aZqdjtSvtNkP2E03agVC/8SqW
> mNyERNFcyOP3hUlNHSghPXl81ckSabqa83rLrwFCZQGJ2U71EnnietYxXT5Dz6Kx
> W03z8HY2mClTETmZB/WvkCmG0F1AXQ8Xr2E4fJ2+meyNHgTZ2XjfYsKtZNKTQmiC
> zlDgweuXuQ1r6DorLB4MUCm7HMffeDTwKEHBaYkIt7reHN8yGfT8sq1F8A0ZDKHi
> y9Ugt0KwePPOGFK8mfST7lBWojPJL1wbyBVAYh+FL5f1hMScOdHRxbU9uz2p9NSB
> RMubUWNCD1p8+sI8bLjQ//vU/iCLcWg7RStr/FSfXZEqjJv6EZ4OaNafahTcxvey
> 37Qz/eVTJQGeYa0+1rBvttVZJB6xrJwcscC3dgskTJ8VXJuAnwK0WdmMRzD7XLos
> HP13SOoLXUgek07XH61OPq5dnbpUwq996GqpSLldLUJlCnbMi1vxkAmGe006zVXH
> GWPoV1d4r7p0JjkyBlGQYUwiltuDFyNOx9uRS5FTaapaarhY6G0=
> =Z571
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> 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
