Apache returning wrong Location header

apache-2.4http-headersredirect

The issue happens when you:

issue a request with the header "Host" including the port, e.g. "Host: www.example.com:80", which is legal as per https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23. You can do it for instance with curl curl -v -H "Host: www.example.com:80" -X GET -i http://www.example.com
the server issues a redirect to https for that request, in my case using the following RewriteRule

RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

I noticed that the "Location" header of the response also includes the port, and it's the same of that specified in the "Host" header of the request. So the server would respond with "Location: https://www.example.com:80", which is wrong.

This happens to me with "Apache/2.4.7 (Ubuntu)", but I noticed the issue also with Varnish cache server. Why does it behave this way? Is there a way to correct this?

Best Answer

HTTP_HOST refers to the Host: header specified, so your configuration works as expected based on what you're telling it to.

If you want to, you can either strip away the port, or specify another by matching it and using a backreference:

Remove port and default to https:

RewriteCond %{HTTP_HOST} ^([^:]+)(:[0-9]+)?$
RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L]

Change the port to something else (8443 here):

RewriteCond %{HTTP_HOST} ^([^:]+)(:[0-9]+)?$
RewriteRule ^ https://%1:8443%{REQUEST_URI} [R=301,L]

Related Solutions

HTTP / Redirecting to a URI on the server

Is it also valid, according to the HTTP/1.1 standard, to send a URI [in a location header] without hostname and protocol?

No, because of how 'absoluteURI' is defined. Since you're looking at an RFC, let's stick to them for this discussion. Backing up:

Now what exactly do they mean by 'absolute URI'?

It's defined elsewhere. This happens often.

Now I want to redirect to a URI on the same server, and I know the path. It is an absolute URI (it starts at the root), but without hostname and protocol.

It might be an absolute path, but that doesn't make it an absolute URI.

From section 3.2.1 of the HTTP/1.1 RFC, General Syntax:

For definitive information on URL syntax and semantics, see "Uniform Resource Identifiers (URI): Generic Syntax and Semantics," RFC 2396 [42] (which replaces RFCs 1738 [4] and RFC 1808 [11]). This specification adopts the definitions of "URI-reference", "absoluteURI", "relativeURI", "port", "host","abs_path", "rel_path", and "authority" from that specification.

Looking at RFC 2396:

   absoluteURI   = scheme ":" ( hier_part | opaque_part )

Even without diving through the BNF, the 'scheme' part (the 'http' or 'https') is required. I'll omit an actual discussion of the rule-building here, but since you need an 'http:' or 'https:' at the beginning of the string, you can't remove the network part of the URI.

I tried this, and every browser I tested seemed to understand it.

Postel's law at work. You did something wrong, but the browser understood it anyway. You should follow it and send a correct absolute URI with your Location: header. If it can't be built easily in your environment, there's something off; I can't think of any web application I've seen where host information is not configurable or retrievable.

Nginx proxy_pass rewrite of response header location

Add a trailing slash to your proxy_pass target.

Update : The OP didn't precise the vhost was accepting https. As the scheme is forwarded to the backend server with additionnal headers, then an issue occurs since proxy_redirect default; orders nginx to expect http scheme by default when rewriting Location headers in upstream replies, instead of https.

So, this had to be changed explicitely to a more generic form (the trailing slash is still necessary) :

location /gitlab/ {
    proxy_pass http://127.0.0.1:9000/;
    proxy_redirect $scheme://$host:$server_port/ /gitlab/;
}

Best Answer

Related Solutions

HTTP / Redirecting to a URI on the server

Nginx proxy_pass rewrite of response header location

Related Topic