Redirects incorrectly set Location header in response when Host header is set in request

Bug #1018285 reported by Michael Williamson
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
apache2 (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

When Apache sends a 301 redirect and the Host header in the request has an implicit port, it incorrectly uses the Host header of the request and the port that Apache is running on to set the Location header.

Steps to reproduce:
  * Get Apache to serve up a directory with a sub-directory "blah" on a particular port, say, 8080.
  * Access the URL "http://localhost:8080/blah" (note no trailing slash) with the Host header "Host: example.com".
  * Note that the Location header in the response is "Location: http://example.com:8080/blah/" rather than "Location http://example.com/blah/" as it should be.

Expected behaviour:
  * A location header that uses the Host header only, rather than combining the Host header and the port Apache is running on.

If the Host header has a port explicitly set, Apache behaves correctly e.g. if the Host header is "Host: example.com:8090", then the Location header in the response is "Location: http://example.com:8090/blah/".

$ apt-cache policy apache2
apache2:
  Installed: 2.2.22-1ubuntu1
  Candidate: 2.2.22-1ubuntu1
  Version table:
 *** 2.2.22-1ubuntu1 0
        500 http://gb.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
        100 /var/lib/dpkg/status

$ lsb_release -rd
Description: Ubuntu 12.04 LTS
Release: 12.04

Revision history for this message
Michael Williamson (michael-williamson) wrote :

It looks like this has been fixed in a later version of Apache -- I've just compiled 2.4.2 from source and it doesn't appear to have the problem.

Revision history for this message
Robie Basak (racb) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better.

Is this really a bug, or a new feature in a future Apache version?

Traditionally, Apache used to issue redirects based on its own knowledge of its own name (and presumably port), rather than using the Host header, didn't it? I'm pretty sure that it used to be the case that it was essential for Apache to know its own name correctly for this reason.

I wonder if upstream considers this a bug? Have they fixed it in the 2.2 series?

Changed in apache2 (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Michael Williamson (michael-williamson) wrote :

> Is this really a bug, or a new feature in a future Apache version?
>
> Traditionally, Apache used to issue redirects based on its own knowledge of
> its own name (and presumably port), rather than using the Host header, didn't
> it?

If that's the case, then surely Apache should ignore the Host header entirely, rather than using the hostname from the Host header, and the port Apache is running on? The fact that it works correctly when the port is explicitly set in the Host header makes me pretty sure this is a bug -- when the port in the Host header isn't explicitly set, it should mean there's an implicit port i.e. port 80 for HTTP, so the behaviour should be consistent whether the port is explicit or implicit in the Host header.

Revision history for this message
Robie Basak (racb) wrote :

Apache has to use the Host header to match a virtual entry. But you may well be right - I'm no authority on this.

I think that to progress with triage of this bug, we need to determine if the latest 2.2 upstream is affected. If it is not, then a backported fix may be justified, so the next step would be to identify the upstream 2.2 series commit that fixed this issue. If the latest 2.2 upstream is not affected, then upstream would be the appropriate place to seek guidance from, perhaps by filing a bug there.

Revision history for this message
Robie Basak (racb) wrote :

Marking as Incomplete for now, since to verify if the bug is valid, I think we need confirmation from upstream - either that their latest 2.2 release built from source does not have the problem, or in the form of a commit in the 2.2 series where they fixed it, or in their acceptance of a bug, or some other form of confirmation. I don't think it's appropriate to seek a fix solely for Ubuntu otherwise. If the situation changes, please comment and change the bug status back to New.

Changed in apache2 (Ubuntu):
status: New → Incomplete
Revision history for this message
Michael Williamson (michael-williamson) wrote :

I've just compiled httpd 2.2.22 from source, and it does not appear to have this bug.

Changed in apache2 (Ubuntu):
status: Incomplete → New
Revision history for this message
Stefan Fritsch (sf-sfritsch) wrote :

Are you sure you have the same configuration for all versions? The behavior is defined by UseCanonicalName and UseCanonicalPhysicalPort:

http://httpd.apache.org/docs/2.2/mod/core.html#usecanonicalphysicalport

The behavior you describe for 2.2.22-1ubuntu1 seems to match the one for "UseCanonicalPhysicalPort on" while the compiled from source behavior seems to correspond to "off"

Revision history for this message
Michael Williamson (michael-williamson) wrote :

I tried adding the line "UseCanonicalPhysicalPort off" to both apache2.conf and to the site configuration (inside the virtualhost declaration), but the port is still included in the Location header. Just to be sure, I also tried "UseCanonicalName off", but it didn't make any difference.

brony4410 (brony44)
Changed in apache2 (Ubuntu):
status: New → Fix Released
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.