Is a 302 redirect to relative URL valid, or invalid?

Question

Based on the RFC it seems like the Location field in an HTTP response for a 302 should be absolute. https://www.rfc-editor.org/rfc/rfc2616#section-14.30

If this statement is correct, do browsers honor this - or do they allow relative paths?

Romalda

Answer 1

Relative URLs are valid.

There is a bug in RFC 2616. See http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-17.html#rfc.section.9.5.

Avelar

Please leave a note in the specs that adding the URI fragment identifier is not in conformance with / different to [RFC3986] absolute / relative URI resolution rules. – Decennary

@Decennary please elaborate over on the Working Group's mailing list – Avelar

As you're the editor I just wanted to ensure you know about this, so thank you for letting me know. QFT "@Decennary please elaborate over on the Working Group's mailing list – Julian Reschke Dec 17 '12 at 7:12" – Decennary

hakre: I have no idea what you're talking about, thus I asked to elaborate -- not here, but in the right forum for that. – Avelar

I also have no idea what the editor does, so we're two here. However I suggest you take a look into the existing RFC where it's written how to resolve a URI against a base URI, then you compare it with the edit(s) you have in HTTP bis and then you see where it starts to squeak. I don't like these mailinglists, so if you don't mind, I'm okay when you just know about it as you're the editor. – Decennary

hakre: if you believe there is a problem, explain it. Otherwise nothing is going to happen. – Avelar

Well test against RFC3986 the resolution rules of location URI against a base URI especially the part with the # fragment identifier. IMHO it's incompatible (which must not be an issue per-se, but if it's intended, please make that visible in the new specs). – Decennary

hakre: the spec says to resolve according to RFC 3986; you really need to properly explain what you think the problem is. And by all means do it where feedback for the specs is expected to go. Over and out. – Avelar

All I say is if it differs from RFC 3986 then please make that visible. Otherwise a statement that this follows RFC 3986 would be useful, too. So the commitment is clear. That's all. Sorry if that sound like lazy reporting to you, but that's how I am. – Decennary

it's not supposed to differ from RFC 3986. – Avelar

What are you talking about? Isn't the question talking about a RFC (a.k.a. de facto standard) while this answer is talking about a Draft (i.e. work in progress)? – Harkey

@JulianReschke: I now checked this and the HTTP standard does not support the empty relative URL to the document itself, the workaround is to use the hash to denote the empty url until then. Headers with an empty Value (which is a valid relative URL) seem to have been forgotten when updating this ... . – Decennary

Answer 2

RFC 2616 requires an absolute URI in the Location, but that standard has been replaced, since June 2014. The relevant specification is now RFC 7231. The relevant section of the new standard says:

Location = URI-reference

The field value consists of a single URI-reference. When it has the form of a relative reference ([RFC3986], Section 4.2), the final value is computed by resolving it against the effective request URI ([RFC3986], Section 5).

So a relative URI is now permitted. The effective request URI is the same as the request URI in most cases.

Bainter