What are the Consequences for using Relative Location Headers?

Question

According to the spec, Location headers used in a redirect require a server name

HTTP/1.1 301 Moved Permanently
...
Location: http://example.com/foo/baz/bar

However, in 2012, most web browsers will recognize a relative path and redirect you to the new location using the original server name

HTTP/1.1 301 Moved Permanently
...
Location: /foo/baz/bar

Are there any negative/surprising consequences to using the relative URLs in the Location headers? My particular concern is how Google/search-engines will interpret this, but if there's anything else I'm not thinking about I'd love to hear it.

Solution 1

According to the current version of the HTTP/1.1 standard, RFC 2616, the value of the Location header must be an absolute URI.

However, in the draft standard prepared by the HTTPbis Working Group to eventually replace RFC 2616, this has been changed to allow relative URIs as well, apparently because:

"The definition of the Location header [in RFC 2616] differs in various ways of how at least Web browsers need to deal with them to interoperate with content on the Web"

In practice, AFAIK just about all major browsers and search engines do understand and accept HTTP redirects to relative URLs. However, until the HTTPbis draft some day becomes the official standard and gets widely adopted, there will always be some new or obscure user agents that implement the current standard to the letter and only accept absolute URLs. Thus, the safe thing to do, for now, is to only use absolute URLs in Location headers, as suggested by Postel's law:

"Be conservative in what you send, liberal in what you accept."

Solution 2

Section 14.30 of the HTTP 1.1 RFC http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30 is not significantly different. I don't know that you're going to see any actual practical limitations for this.

The only time I've seen even a warning about this issue is when I used to test in Lynx and the location was not absolute it would warn you "Location value not absolute" -- but if I remember right it still would let you go to the new location. I just tested Lynx 2.8.7 and it appears it doesn't do that anymore, though that may be a configuration issue.

Now, you say:

My particular concern is how Google/search-engines will interpret this, but if there's anything else I'm not thinking about I'd love to hear it.

I believe that this warrants a test. I'd set up a url, put it in your site's xml sitemap, and have that url be a redirect as you describe. I think the thing to do is check it using Google Webmaster Tools and see if there are negative consequences.

Comments

[Su']

Could you quote the exact bit you're getting that requirement from? Not challenging, I just don't immediately see it and don't feel like reading an entire RFC to find it. Also, you're citing the HTTP 1.0 spec but using HTTP 1.1 headers in your examples. (Which may or may not change the allowed content.)

[Alan Storm]

The 10.11 section. tools.ietf.org/html/rfc1945#page-44 There's also nothing, to my knowledge, in the 1.1 spec that "fixes" this.