86

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?

Community
  • 1
  • 1
GeorgeU
  • 7,819
  • 8
  • 26
  • 38

2 Answers2

172

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.

Community
  • 1
  • 1
Raedwald
  • 46,613
  • 43
  • 151
  • 237
31

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.

Rich
  • 15,048
  • 2
  • 66
  • 119
Julian Reschke
  • 40,156
  • 8
  • 95
  • 98
  • 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. – hakre Dec 17 '12 at 01:56
  • @hakre please elaborate over on the Working Group's mailing list – Julian Reschke Dec 17 '12 at 07:12
  • As you're the editor I just wanted to ensure you know about this, so thank you for letting me know. QFT *"@hakre please elaborate over on the Working Group's mailing list – Julian Reschke Dec 17 '12 at 7:12"* – hakre Jan 23 '13 at 10:28
  • hakre: I have no idea what you're talking about, thus I asked to elaborate -- not here, but in the right forum for that. – Julian Reschke Jan 24 '13 at 08:38
  • 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. – hakre Jan 24 '13 at 12:51
  • hakre: if you believe there is a problem, explain it. Otherwise nothing is going to happen. – Julian Reschke Jan 25 '13 at 06:51
  • 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). – hakre Jan 25 '13 at 23:11
  • 1
    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. – Julian Reschke Jan 26 '13 at 09:59
  • 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. – hakre Jan 26 '13 at 10:39
  • it's not supposed to differ from RFC 3986. – Julian Reschke Jan 26 '13 at 11:22
  • 6
    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)? – BlaM Feb 19 '13 at 16:45
  • @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 ... . – hakre Aug 18 '23 at 21:03