Search code examples
httpurlcookiessession-cookiesrfc3986

Is a URL with // in the path-section valid?

I have a question regarding URLs:

I've read the RFC 3986 and still have a question about one URL:

If a URI contains an authority component, then the path component
must either be empty or begin with a slash ("/") character. If a URI does not contain an authority component, then the path cannot begin
with two slash characters ("//"). In addition, a URI reference
(Section 4.1) may be a relative-path reference, in which case the
first path segment cannot contain a colon (":") character. The ABNF
requires five separate rules to disambiguate these cases, only one of which will match the path substring within a given URI reference. We use the generic term "path component" to describe the URI substring
matched by the parser to one of these rules.

I know, that //server.com:80/path/info is valid (it is a schema relative URL)

I also know that http://server.com:80/path//info is valid.

But I am not sure whether the following one is valid:

http://server.com:80//path/info

The problem behind my question is, that a cookie is not sent to http://server.com:80//path/info, when created by the URI http://server.com:80/path/info with restriction to /path

Solution

  • See url with multiple forward slashes, does it break anything?, Are there any downsides to using double-slashes in URLs?, What does the double slash mean in URLs? and RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax.

    Consensus: browsers will do the request as-is, they will not alter the request. The / character is the path separator, but as path segments are defined as:

    path-abempty  = *( "/" segment )
segment       = *pchar

    Means the slash after http://example.com/ can directly be followed by another slash, ad infinitum. Servers might ignore it, but browsers don't, as you have figured out.

    The phrase:

    If a URI does not contain an authority component, then the path cannot begin with two slash characters ("//").

    Allows for protocol-relative URLs, but specifically states in that case no authority (server.com:80 in your example) may be present.

    So: yes, it is valid, no, don't use it.