[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