Re: Should allowHostHeaderMismatch be case sensitive
On 15/12/2023 14:48, Christopher Schultz wrote: Do we need to argue over encoding and/or rules of case-insensitive-matching? Could we? Probably. Do we need to? Unlikely. My expectation is that most clients aren't even including the host in the request line these days. Non-ASCII hostnames are allowed these days. Depending upon when this comparison is done, the strings may or may not have been normalized. Case-normalization can be expensive if you want to be as encoding, language, etc. agnostic as possible. Yes this is a theoretical risk but one I don't expect to materialize. My expectation is that clients new enough to use non-ascii host names also don't put the header in the request line or if they do, they make sure it matches the Host header. Perhaps we could perform a byte-wise comparison first (which is very likely to succeed quickly) and, if that fails, fall-back to a more thorough normalization/comparison? That is probably the way to go if we decide in the future that we do need to do the normalization first. In which case I'd lean more towards using toString() and then getting Java to do the comparison. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Should allowHostHeaderMismatch be case sensitive
Mark, On 12/15/23 04:12, Mark Thomas wrote: On 11/12/2023 17:20, Mark Thomas wrote: On 11/12/2023 17:08, David Cleary wrote: Just want to check if this is by design. The above property default was changed to better secure the default configuration. We started having some tests fail due to this. In our scenario ( as shown below ), the Host header value in the HTTP request is case-sensitive difference compared to the Request Line, and it's crucial that Tomcat, our web server, does not block or reject requests based on variations in the letter case within this header. Request Line: GET http://HZN-OE-A079:8080 HTTP/1.1 Host header: hzn-oe-a079:8080 Just want to confirm that this property, now with a default of false, is supposed to reject requests based on the case of the host name. David, Host names are case insensitive so I can see the argument for making this comparison in a case insensitive manner. However, the language in RFC 9112, section 3.2 is: A client MUST send a Host header field (Section 7.2 of [HTTP]) in all HTTP/1.1 request messages. If the target URI includes an authority component, then a client MUST send a field value for Host that is identical to that authority component, excluding any userinfo subcomponent and its "@" delimiter (Section 4.2 of [HTTP]). The key word for me in the above is identical. We probably need to go back to the HTTP working group and clarify whether then intention was for that "identical" to be in a case sensitive or insensitive manner. https://lists.w3.org/Archives/Public/ietf-http-wg/2023OctDec/0247.html Based on that discussion, I am going to relax the check to case insensitive. +1 Do we need to argue over encoding and/or rules of case-insensitive-matching? Non-ASCII hostnames are allowed these days. Depending upon when this comparison is done, the strings may or may not have been normalized. Case-normalization can be expensive if you want to be as encoding, language, etc. agnostic as possible. Perhaps we could perform a byte-wise comparison first (which is very likely to succeed quickly) and, if that fails, fall-back to a more thorough normalization/comparison? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Should allowHostHeaderMismatch be case sensitive
On 11/12/2023 17:20, Mark Thomas wrote: On 11/12/2023 17:08, David Cleary wrote: Just want to check if this is by design. The above property default was changed to better secure the default configuration. We started having some tests fail due to this. In our scenario ( as shown below ), the Host header value in the HTTP request is case-sensitive difference compared to the Request Line, and it's crucial that Tomcat, our web server, does not block or reject requests based on variations in the letter case within this header. Request Line: GET http://HZN-OE-A079:8080 HTTP/1.1 Host header: hzn-oe-a079:8080 Just want to confirm that this property, now with a default of false, is supposed to reject requests based on the case of the host name. David, Host names are case insensitive so I can see the argument for making this comparison in a case insensitive manner. However, the language in RFC 9112, section 3.2 is: A client MUST send a Host header field (Section 7.2 of [HTTP]) in all HTTP/1.1 request messages. If the target URI includes an authority component, then a client MUST send a field value for Host that is identical to that authority component, excluding any userinfo subcomponent and its "@" delimiter (Section 4.2 of [HTTP]). The key word for me in the above is identical. We probably need to go back to the HTTP working group and clarify whether then intention was for that "identical" to be in a case sensitive or insensitive manner. https://lists.w3.org/Archives/Public/ietf-http-wg/2023OctDec/0247.html Based on that discussion, I am going to relax the check to case insensitive. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Should allowHostHeaderMismatch be case sensitive
On 11/12/2023 17:08, David Cleary wrote: Just want to check if this is by design. The above property default was changed to better secure the default configuration. We started having some tests fail due to this. In our scenario ( as shown below ), the Host header value in the HTTP request is case-sensitive difference compared to the Request Line, and it's crucial that Tomcat, our web server, does not block or reject requests based on variations in the letter case within this header. Request Line: GET http://HZN-OE-A079:8080 HTTP/1.1 Host header: hzn-oe-a079:8080 Just want to confirm that this property, now with a default of false, is supposed to reject requests based on the case of the host name. David, Host names are case insensitive so I can see the argument for making this comparison in a case insensitive manner. However, the language in RFC 9112, section 3.2 is: A client MUST send a Host header field (Section 7.2 of [HTTP]) in all HTTP/1.1 request messages. If the target URI includes an authority component, then a client MUST send a field value for Host that is identical to that authority component, excluding any userinfo subcomponent and its "@" delimiter (Section 4.2 of [HTTP]). The key word for me in the above is identical. We probably need to go back to the HTTP working group and clarify whether then intention was for that "identical" to be in a case sensitive or insensitive manner. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
