[squid-users] Squid returns 400 to GET / HTTP/1.1 with Host Header
Stephen Nelson-Smith
sanelson at gmail.com
Mon Apr 23 15:48:22 UTC 2018
Hi Amos,
On Mon, Apr 23, 2018 at 4:31 PM, Amos Jeffries <squid3 at treenet.co.nz> wrote:
>> From the RFC it seems like Redbot's request is perfectly valid, and so
>> I feel like Squid should do the right thing and deduce from the host
>> header what Redbot wants, and go through its ACLs. However, it just
>> errors with:
>
> You missed the part where it says which type of recipient the various
> URL forms are valid.
>
> The redbot example is a origin-form URL - valid only when sent to origin
> servers (or reverse-proxy). The curl one is an absolute-form URL - valid
> when sent to proxies and gateways.
Thanks - that's a helpful distinction.
>> Does this seem like a Squid config issue? Or do I need to make Redbot
>> make a request like Curl does?
>
> Redbot is designed primarily for debugging HTTP problems with origin
> servers to check why their output is not caching in a proxy or browser
> properly. If you can find an option to inform it that it is operating
> through a proxy, turn that on.
There's no such option, and I had to modify RedFetcher to instantiate
with a proxy. The constructor does support it, but there's no login
in Thor or Redbot to behave differently if going through a proxy.
Adding that functionality would be an option, but am I right in
thinking squid should be able to infer the destination from the host
header?
Just looking at the documentation for http_port, would adding
'intercept' help, or is that explicitly for interception caching in
conjunction with a traffic filter?
S.
More information about the squid-users
mailing list