jvgutierrez opened a new issue, #9094:
URL: https://github.com/apache/trafficserver/issues/9094

   We are experiencing an unexpected behavior when requests reach ATS without a 
leading /. An easy PoC: `curl http://127.0.0.1:3128 --request-target 
favicon.ico`. Per my current understanding of [RFC 9112 Section 3.2 Request 
Target](https://www.rfc-editor.org/rfc/rfc9112.html#name-request-target), this 
should result in a 400 response cause request-target doesn't comply with any of 
the expected forms:
   ```
     request-target = origin-form
                    / absolute-form
                    / authority-form
                    / asterisk-form
   ```
   origin-form is defined like this:
   ```
   origin-form    = absolute-path [ "?" query ] # 
https://www.rfc-editor.org/rfc/rfc9112.html#name-origin-form
   absolute-path  = 1*( "/" segment ) # 
https://www.rfc-editor.org/rfc/rfc9110.html#name-uri-references
   ```
   and the RFC explicitly mentions `When making a request directly to an origin 
server, other than a CONNECT or server-wide OPTIONS request (as detailed 
below), a client MUST send only the absolute path and query components of the 
target URI as the request-target.`
   
   The other kind of request targets are defined like this:
   ```
     absolute-form   = absolute-URI # 
https://www.rfc-editor.org/rfc/rfc9112.html#name-absolute-form
     absolute-URI    = scheme ":" hier-part [ "?" query ] # 
https://www.rfc-editor.org/rfc/rfc3986.html#section-4.3
     authority-form  = uri-host ":" port # 
https://www.rfc-editor.org/rfc/rfc9112.html#name-authority-form
     asterisk-form   = "*" # 
https://www.rfc-editor.org/rfc/rfc9112.html#name-asterisk-form
   ```
   
   What we are seeing with both ATS 9.1.3 and ATS 8.0.8 is that ATS takes this 
request as "absolute-form" (thanks @maskit for pointing it out) and as defined 
in [RFC 9112 Section 3.2.2 absolute-form 
](https://www.rfc-editor.org/rfc/rfc9112.html#name-absolute-form)ATS ignores 
the received Host header and replaces it with the host information of the 
request target.
   
   This results in the following request reaching the origin server:
   ```
   GET / HTTP/1.1
   Host: favicon.ico
   User-Agent: curl/7.64.0
   Accept: */*
   ```
   
   I've tested at least two other major HTTP proxy implementations and both of 
them generate the following request for the origin server:
   ```
   GET favicon.ico HTTP/1.1
   Host: 127.0.0.1:3128
   User-Agent: curl/7.64.0
   Accept: */*
   ```
   
   IMHO ATS should comply with RFC 9112 and just return a 400 response. In our 
current production environment this is triggering connection errors against 
origin servers cause those happen over TLS and we enforce the validation of the 
servername 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to