On 17/10/19 11:33 pm, jl wrote: > Thanks both for your replies. > >>>> Or for this: >>>> curl -v -k -x IP:PORT http://192.121.151.106/doc/search/ -H "Host: >>>> erlang.org" >>>> >>>> to return "HTTP/1.1 200 OK" instead of "HTTP/1.1 404 Not Found" > > >> That one is not a good idea. The origin server is producing that 404, >> nothing to do with Squid. > > But in this case the Host header resolves to the IP in the URL and if we > simply do `curl -v -k -x IP:PORT http://erlang.org/doc/search/` it returns a > "HTTP/1.1 200 OK". Shouldn't be possible for Squid to use the Host header > instead of the IP in such cases and not rewriting the Host header with the > IP? Or such behavior would go against the RFC 7230 (HTTP/1.1): > > When a proxy receives a request with an absolute-form of > request-target, the proxy MUST ignore the received Host header field > (if any) and instead replace it with the host information of the > request-target. A proxy that forwards such a request MUST generate a > new Host field-value based on the received request-target rather than > forward the received Host field-value > > ? It leads to issues like this one: <http://www.squid-cache.org/Advisories/SQUID-2011_1.txt> (but in a way that does not require interception to trigger.) side-effects of those type of vulnerability are cache injection, network hijacking, cross-site scripting, the cited same-origin bypass, and the source of the problems being granted anonymity. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
