3

Most if not all browsers support the following notation:

<script src="//domain.com/script.js">

The // notation means use the same protocol as the current one, i.e.:

  • http://domain.com/script.js if the current page has been served over HTTP
  • https://domain.com/script.js if the current page has been served over HTTPS

This notation works with other HTML tags as well: <a>, <link>, etc.

Is this notation also valid for the Location header?

For example, is it valid to reply this:

HTTP/1.0 301 Moved Permanently
Location: //domain.com/other-resource
BenMorel
  • 34,448
  • 50
  • 182
  • 322
  • The Location header should contain an absolute path if I recall it correctly from the specs, but in practice many clients also accept paths (like `/index.html`). I do not know if clients also support `//example.com/index.html` though. (*many* clients, not all. IIRC some CLI browser did not support it, `lynx` or `w3m` (my memory is likely failing here...)) – Lekensteyn Oct 07 '13 at 22:26
  • 2
    It's worth noting that though an absolute URI is technically required ... in practice user agents must resolve location headers using this form because so many sites erroneously use relative values here. In these cases the resolving algorithm specified in [RFC 3986 Section 5.2](http://www.ietf.org/rfc/rfc3986.txt) is needed. –  Oct 08 '13 at 12:30
  • 1
    possible duplicate of [Is a 302 Redirect to relative URL valid, or invalid?](http://stackoverflow.com/questions/8250259/is-a-302-redirect-to-relative-url-valid-or-invalid) – Raedwald Sep 03 '14 at 11:50
  • @Raedwald Nope, the question you're linking to is about relative vs absolute URLs, whereas my question was about the `//` notation, which is a placeholder for the scheme of the current URL. – BenMorel Sep 03 '14 at 12:04
  • What you call "the `//` notation" is a [URI relative reference](https://tools.ietf.org/html/rfc3986#section-4.2), "A relative reference that begins with two slash characters is termed a network-path reference", so yes, this question *is* a duplicate of [Is a 302 Redirect to relative URL valid, or invalid?](http://stackoverflow.com/questions/8250259/is-a-302-redirect-to-relative-url-valid-or-invalid). – Raedwald Sep 03 '14 at 12:21
  • Hmm, fair enough, I actually needed to re-read the accepted answer below to refresh my memory! – BenMorel Sep 03 '14 at 12:55

3 Answers3

1

A URL starting with // is an example of a relative URL.

The Location-header needs an absolute URL, which means the answer you are looking for unfortunately is: no, it's not supported.

This is specified in Section 14.30 of RFC2616 on HTTP/1.1:

The field value consists of a single absolute URI.

Edit: But please consider the comments attached to this answer. My answer should maybe have been qualified by "according to the currently accepted published standard" or something. I am not the one to ask about what exists in reality ;)

Magnus Hoff
  • 21,529
  • 9
  • 63
  • 82
  • You are citing an outdated spec; see http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-24.html#header.location – Julian Reschke Oct 08 '13 at 06:20
  • 2
    @magnus is *not* citing an outdated spec. – PeeHaa Oct 08 '13 at 08:58
  • @JulianReschke what part of the word "draft" is unclear? No, RFC2616 isn't going anywhere for the time being. –  Oct 08 '13 at 12:22
  • rdlowrey: as IETF contributor I'm aware what "draft" means. This part of the draft hasn't changed in ~3 years, it reflects both what existing code does and what the Working Group thinks is correct. The draft has passed two Working Group Last Calls without anybody challenging this change. It's now lined up for IETF Last Call. So, no, continuing to cite RFC 2616 with respect to this isn't helpful at all. It's simply misleading. – Julian Reschke Oct 08 '13 at 12:29
  • 2
    @JulianReschke A draft is a draft is a draft. Telling people to ignore RFC2616 is irresponsible. A [good answer](http://stackoverflow.com/questions/19235829/does-the-location-header-accept-the-protocol-notation/19235867#comment28491526_19235829) would have provided a real solution instead of misleading people. –  Oct 08 '13 at 12:33
  • 1
    rdlowrey: a draft is a draft, but this is a very advanced draft close to replacing 2616. Telling people to ignore the draft when in fact it reflects what code already does is what's irresponsible. – Julian Reschke Oct 08 '13 at 12:40
  • FWIW, the aforementioned draft indeed has been published as RFC 7231, obsoleting RFC 2616. So the answer definitively is incorrect. – Julian Reschke Sep 09 '14 at 06:16
1

No that is not valid. Neither does it really make that much sense:

The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource. For 201 (Created) responses, the Location is that of the new resource which was created by the request. For 3xx responses, the location SHOULD indicate the server's preferred URI for automatic redirection to the resource. The field value consists of a single absolute URI.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30

If you know there is an secure URL available why would it matter what protocol the current page uses?

PeeHaa
  • 71,436
  • 58
  • 190
  • 262
  • Because I want to leave it up to the client to use HTTP or HTTPS, and not enforce the secure page even though there is one! – BenMorel Oct 07 '13 at 23:27
  • Yes, it is valid. See http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-24.html#header.location – Julian Reschke Oct 08 '13 at 06:20
  • @JulianReschke You couldn't be more wrong. You are citing a **draft**. Please don't make up shit. – PeeHaa Oct 08 '13 at 08:51
  • PeeHaa - the draft reflects both running code and working group consensus; if you believe it's wrong you'd better send feedback soon. – Julian Reschke Oct 08 '13 at 11:48
  • 4
    I dont' think the draft is wrong. What is wrong is you saying it is valid while it clearly is not under current standards. – PeeHaa Oct 08 '13 at 12:53
0

It is not valid per RFC 2616, but it works in practice and is valid in the current revision of HTTP/1.1 (see http://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7231.html#rfc.section.7.1.2)

Julian Reschke
  • 40,156
  • 8
  • 95
  • 98
  • 3
    Equally though, you're citing a *draft* spec - it's *likely* that it will be valid in the next *published* revision but not 100% guaranteed. – Damien_The_Unbeliever Oct 08 '13 at 06:27
  • Damien: the draft reflects both running code and working group consensus; if you believe it's wrong you'd better send feedback soon. – Julian Reschke Oct 08 '13 at 11:49
  • 3
    Also, just citing from your draft: _"[...]. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress”."_ – bwoebi Oct 08 '13 at 20:06
  • 2
    **I originally downvoted because ...** the answer should have been: *"Officially, no you aren't supposed to do that. In reality user-agents have been forced to use the RFC 3986 matching algorithm for years because developers couldn't be bothered to follow the rule. In three or four years when HTTP/2.0 comes along it will be technically okay but it hasn't mattered for years and is allowed de facto."* But this is not what you said. Now that you've updated your answer I'm happy to rescind my downvote. Correctness is what matters -- not feelings :) –  Oct 08 '13 at 20:09
  • rdlowrey: this is HTTP/1.1, not 2.0 – Julian Reschke Oct 08 '13 at 20:40