squid in lucid adds bogus port number to Host: line if one isn't provided (in original or via vport=)

Bug #640511 reported by James Troup
12
This bug affects 2 people
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

Revision history for this message
Amos Jeffries (yadi) wrote :

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.

Changed in squid:
importance: Unknown → Undecided
status: Unknown → New
Changed in squid (Ubuntu):
status: New → Invalid
Changed in squid:
status: New → Invalid
Revision history for this message
Henrik Nordström (henriknordstrom) wrote :

It is not clear to me which Squid versions this relates to.

Looked over the vport logics one more time, and squid-2 did behave a bit odd and unexpected there. Squid-2 HEAD/trunk patch which should fix this at http://www.squid-cache.org/Versions/v2/2.HEAD/changesets/12698.patch and probably backports to Squid-2.7 as well.

Squid-3 do not have this issue from what I can tell.

Revision history for this message
Robert Collins (lifeless) wrote : Re: [Bug 640511] Re: squid in lucid adds bogus port number to Host: line if one isn't provided (in original or via vport=)

@Amos defaulting the port is one thing; setting it rather arbitrarily
in the forwarded header is another thing altogether.

@Henrik - thanks for finding that, I'll have a poke shortly at it.

Revision history for this message
Henrik Nordström (henriknordstrom) wrote :

Wasn't arbitraty. But it incorrectly considered a Host: header without port as no port specified and then fell back on vport or socket port in order.

Revision history for this message
Robert Collins (lifeless) wrote :

Confirming, because it was confused :). We'll want to put this patch in the 2.7 packages; it is surprising sysadmins.

Changed in squid:
status: Invalid → In Progress
Changed in squid (Ubuntu):
status: Invalid → Confirmed
Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :

Robert, are you working on a fix ?

tags: added: lucid regression-release
removed: regression-potential
Changed in squid (Ubuntu Lucid):
status: New → Confirmed
importance: Undecided → Medium
description: updated
Revision history for this message
Rolf Leggewie (r0lf) wrote :

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".

Changed in squid (Ubuntu Lucid):
status: Confirmed → Won't Fix
Revision history for this message
Amos Jeffries (yadi) wrote :

Squid-2 has long been obsolete upstream. Now that affected Ubuntu are no longer supported we can close.

Changed in squid:
status: In Progress → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.