Are your redirects HTTP compliant (absolute URI)?

Question

In the Hypertext Transfer Protocol 1.1 spec, it states for the Location header:

The field value consists of a single absolute URI.

   Location       = "Location" ":" absoluteURI

An example is:

   Location: http://www.w3.org/pub/WWW/People.html

I have coded many an app that doesn't include the scheme and domain (i.e., /thankyou/) and every browser I've ever tested with redirects correctly. I'm wondering if it's imperative to go back and change all my redirect code or just ignore this part of the spec.

Have many of you produced code that doesn't comply and will you go back and change it if possible? Or will you just trust that clients will continue to resolve them well into the future?

(going forward I will certainly adhere to this)

Answer 1

Wikipedia gives an explanation about this

But also:

You shouldn't need to to make it relative: the browser should always give the "Host" HTTP header which should enable you to generate an absolute URL.

Answer 2

With the amount of programs and scripts written to do that, I don't think it will ever be an issue. If browsers and webserver's stop supporting it, then they will also stop supporting a large subset of apps.

IMHO, Just write it to how you prefer. If you rarely ever look at the HTML output, then use the full URL. If you want clean looking HTML, then use the shorthand.

Answer 3

Since browsers have to accept various forms for link targets, they might as well reuse the code for handling redirects. While sending a relative path is pretty likely to work, it's easy enough to call your own function that adds a protocol and hostname to the front of a path before redirecting.

Answer 4

See HTTPbis WG, Ticket 185.

Answer 5

Use the correct method of redirecting going forward.

As for old code, rely on your post-sale process to detect any problems and resolve if and when it is commercially viable. If nobody ever raises a bug because all browsers handle the relative URI, you don't really need to fix it - but writing things correctly in your new code means you know it will work correctly even in some obscure browser that has yet to take off and that adheres very strictly to the standard.

Answer 6

Have many of you produced code that doesn't comply and will you go back and change it if possible?

It depends on the compliance. If my code is the only example of non compliance then it is should be changed. As what you are experiencing as working could be a side effect of your environment or setup.

Or will you just trust that clients will continue to resolve them well into the future?

If something is considered a general workaround to a problem then you may trust this. For the medium term at least. It may be worth investigating the progress of the standards. You may find that what you are doing is a Should not rather than a must not in which case you may want to change as future versions of the spec my change to a must not

Conversely you may find that your non compliance is actually going to be compliant in the next version of the spec and clients are supporting it ahead of time. Many browsers support some HTML 5 features even though the spec is not final yet.

Answer 7

I would go with the absolute URI. Both the absolute and relative URIs may work now, but who knows what tomorrow brings? It sure feels safer to go by the book, although that is, of course, constantly revised. This is, after all, the web we 're talking about...

As for any kind of "trust" towards current HTTP clients? I might, if any of them decided to actually strictly adhere to web standards for a change...