Hi, This makes sense now. Thank you for clarifying.
Best, Alvaro ________________________________ From: Christopher Schultz <ch...@christopherschultz.net> Sent: Monday, May 8, 2023 5:04 PM To: users@tomcat.apache.org <users@tomcat.apache.org> Subject: [EXTERNAL] Re: Question in regards to the Connector allowHostHeaderMismatch when it is set to "false" Alvaro, On 5/8/23 10:39, Mark Thomas wrote: > On 08/05/2023 13:52, Alvaro Garay wrote: >> Hi Mark, >> >> In the example above...the port remains the same (8143). How is it >> different? > > GET http://myhostname.company.com/api/v1/endpoint HTTP/1.1 > > The host is "myhostname.company.com" > > Host: myhostname.company.com:8143 > > The host is "myhostname.company.com:8143" > > "myhostname.company.com" != "myhostname.company.com:8143" > > The port the client connects to is irrelevant. All that matters is the > host in the request line and the host header. > > 1. The host header MUST be present > 2. If a host is present in the request line it MUST be identical (host > and port) to the host header. nb the spec says that the URL takes precedence if there is a mismatch, but when setting allowHostHeaderMismatch="false" (the current default), then Tomcat is being stricter than the spec. The reason Tomcat is being stricter than the spec by default is because usually Host <> URL host mismatch is an indication that the client is doing something it should not be doing. -chris >> From: Mark Thomas <ma...@apache.org> >> Sent: Friday, May 5, 2023 4:56 PM >> To: Tomcat Users List <users@tomcat.apache.org> >> Subject: [EXTERNAL] Re: Question in regards to the Connector >> allowHostHeaderMismatch when it is set to "false" >> >> >> 5 May 2023 18:21:02 Alvaro Garay <alvaro.ga...@ibm.com.INVALID>: >> >>> Hi, >>> >>> >>> Tomcat version: 9.0.73 >>> >>> Operating system: Unix z/OS System >>> >>> >>> >>> I have a question in regard to the Connector attribute >>> allowHostHeaderMismatch=false which checks the request line is >>> consistent with the Host Header. >>> >>> So in this scenario, I have the request line using the absolute path >>> with a conflicting host header. The response is 400 Bad Request from >>> Tomcat, which makes sense. >>> >>> telnet myhostname.company.com 8143 >>> GET http://myhostname.company.com/api/v1/endpoint HTTP/1.1 >>> Host: facebook.com >>> >>> >>> If I define a valid host header now, then the request is a success. So >>> all is good. >>> >>> telnet myhostname.company.com 8143 >>> GET http://myhostname.company.com/api/v1/endpoint HTTP/1.1 >>> Host: myhostname.company.com >>> >>> telnet 1.1.1.1 8143 >>> GET http://1.1.1.1/api/v1/endpoint HTTP/1.1 >>> Host: 1.1.1.1 >>> >>> However, as soon as I define a port number in the host header with >>> syntax <hostname>:<port> then I get 400 Bad Request from Tomcat. >>> >>> telnet myhostname.company.com 8143 >>> GET http://myhostname.company.com/api/v1/endpoint HTTP/1.1 >>> Host: myhostname.company.com:8143 >>> >>> HTTP/1.1 400 >>> Content-Type: text/html;charset=utf-8 >>> Content-Language: en >>> Content-Length: 762 >>> Date: Fri, 05 May 2023 15:27:09 GMT >>> Connection: close >>> >>> <!doctype html><html lang="en"><head><title>HTTP Status 400 \u2013 Bad >>> Request</title><style type="text/css">body >>> {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b >>> {color:white;background-color:#525D76;} h1 {font-size:22px;} h2 >>> {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a >>> {color:black;} .line >>> {height:1px;background-color:#525D76;border:none;}</style></head><body><h1>HTTP >>> Status 400 \u2013 Bad Request</h1><hr class="line" /><p><b>Type</b> >>> Status Report</p><p><b>Description</b> The server cannot or will not >>> process the request due to something that is perceived to be a client >>> error (e.g., malformed request syntax, invalid request message framing, >>> or deceptive request routing).</p><hr class="line" /><h3>Apache >>> Tomcat/9.0.73</h3></body></html> >>> >>> This request should be allowed right? >> >> No. Different port means a different host so Tomcat correctly rejects the >> request. >> >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
