squid in lucid adds bogus port number to Host: line if one isn't provided (in original or via vport=)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Squid |
Won't Fix
|
Undecided
|
Unassigned | ||
squid (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned | ||
Lucid |
Won't Fix
|
Medium
|
Unassigned |
Bug Description
Binary package hint: squid
After upgrading to lucid we noticed that squid was adding the
http_port port number to any Host: line that came in without port
number. Our setup looks (something like) this:
SSL termination -> squids -> backends
Once these squids beceame lucid, the backends started seeing 'Host:
example.com:3128' instead of 'Host: example.com' (what the original
requestor actually sent). This is a) totally bogus and b) breaks some
of our backends (they 500 if asked to process a request which has a
host line with a port number they're not listening on). We're able to
work around this for some hosts by explicitly specifying 'vport=80' as
an option to 'http_port' but this doesn't work when we have multiple
backends on the same IP but different ports.
== Regression details ==
Discovered in version: lucid
Last known good version: hardy
This is a feature designed for maximum compatibility with other software.
From squid developer discussions:
" hno:
default port in accel mode is the listening port unless told otherwise by the host header or vport. If you run Squid on port 3128 but it's actually processing port 80 requests then you need to tell this to squid with vport=80. It's hard to automatically account for NATs or other reverse proxies infront remapping things in unexpected manners without config hints.
this default port == listening port is needed to support accel mode on non-port80 in an clean manner.
note that you also have this same issue for the same reasons if you run Squid (:80) -> Apache (:8080) unless you tell Apache to override it's idea of the listening port.
the short answer is: Do not remap ports in reverse proxy setups, doing so always bites back one way or another. Use IP addresses instead for request routing purposes.
"
In response to the multiple backends problem:
If the backends are themselves configurable to separate the domain/port they are listening on from the public domain/port this is a non issue.
Squid can listen on multiple ports quite happily, each of which will perform this same Host: re-writing to its own number and can (a) be dedicated to requests going to certain backends using that port. or (b) have their own vport=N option correcting the port back to the public one for subsequent URL generation.