OK to skip slash before query string?

Question

Is it safe to always skip the trailing slash when appending a query string?

That is, can I use

http://example.com?querystring

instead of:

http://example.com/?querystring

? All webhosts I've used support this but is it safe to assume that all server environments will support this method? Is it standard?

Answer 1

As a matter of modern spec, yes, it is permissible to skip the slash, contrary to what the accepted answer here claims.

Although the accepted answer correctly quotes RFC 1738 (released over 20 years ago!), it wrongly claims that RFC 2396 (released in 1998) requires the slash, and neglects that both of those specs have in turn been obsoleted by RFC 3986, released in 2005 (still several years before the accepted answer was written) and more recently by the WhatWG URL Standard, both of which allow the slash to be omitted.

Let's consider each of these specs in turn, from earliest to latest:

---

RFC 1738: Uniform Resource Locators (URL) (released in 1994)

Implicitly requires the slash to be included by specifying that it may be omitted if the URL contains neither a path nor a query string (called a searchpart, here). Bolding below is mine:

An HTTP URL takes the form:

http://<host>:<port>/<path>?<searchpart>

where <host> and <port> are as described in Section 3.1. If :<port> is omitted, the port defaults to 80. No user name or password is allowed. <path> is an HTTP selector, and <searchpart> is a query string. The <path> is optional, as is the <searchpart> and its preceding "?". If neither <path> nor <searchpart> is present, the "/" may also be omitted.

---

RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax (released in 1998; "updates" RFC 1738)

Here it is acceptable to omit the slash. This RFC legalises some weird URL syntaxes that don't have a double-slash after the scheme, but if we ignore those (they're the ones with an opaque_part in the spec's BNF) and stick to URLs that contain a host, then we find that an absoluteURI is defined like this...

absoluteURI   = scheme ":" ( hier_part | opaque_part )

and that a hier_part looks like this:

hier_part     = ( net_path | abs_path ) [ "?" query ]

and that a net_path looks like this:

net_path      = "//" authority [ abs_path ]

where an abs_path is in turn defined to start with a slash. Note that the abs_path is optional in the grammar above - that means that a URL of the form scheme://authority?query is completely legal.

The motivation for this change is hinted at in appendix G.2. Modifications from both RFC 1738 and RFC 1808:

The question-mark "?" character was removed from the set of allowed characters for the userinfo in the authority component, since testing showed that many applications treat it as reserved for separating the query component from the rest of the URI.

In other words - code in the real world was assuming that the first question mark in a URL, anywhere, marked the beginning of a query string, and so the spec was pragmatically updated to align with reality.

---

RFC 3986: Uniform Resource Identifier (URI): Generic Syntax (released in 2005; "obsoletes" RFC 2396)

Again, it is permissible to omit the slash. The spec expresses this by saying that a "path" is required in every URI that contains an authority (host), and that path must either begin with a slash or consist of no characters:

3. Syntax Components

The generic URI syntax consists of a hierarchical sequence of components referred to as the scheme, authority, path, query, and fragment.

URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

hier-part   = "//" authority path-abempty
            / path-absolute
            / path-rootless
            / path-empty

The scheme and path components are required, though the path may be empty (no characters). When authority is present, the path must either be empty or begin with a slash ("/") character.

For completeness, note that path-abempty is later defined thus:

path-abempty  = *( "/" segment )

This does indeed permit it contain no characters.

---

URL Standard by WhatWG (a living standard under active maintenance, first created in 2012, with the goal of obsoleting RFC 3986)

Again, omitting the slash is acceptable, although this time we have no BNF to look at but instead need to read lots of prose.

Section 4.3 tells us:

An absolute-URL string must be one of the following

• a URL-scheme string that is an ASCII case-insensitive match for a special scheme and not an ASCII case-insensitive match for "file", followed by ":" and a scheme-relative-special-URL string
• a URL-scheme string that is not an ASCII case-insensitive match for a special scheme, followed by ":" and a relative-URL string
• a URL-scheme string that is an ASCII case-insensitive match for "file", followed by ":" and a scheme-relative-file-URL string

any optionally followed by "?" and a URL-query string.

Since HTTP and HTTPS are special schemes, any HTTP or HTTPS URL must satisfy the first of those three options - that is, http: or https: followed by a scheme-relative-special-URL string, which:

must be "//", followed by a valid host string, optionally followed by ":" and a URL-port string, optionally followed by a path-absolute-URL string.

A path-absolute-URL string is defined to start with a slash, but is explicitly optional in the definition of an absolute-URL string above; thus, it is permissible to go straight from the host to the "?" and query string, and so URLs like http://example.com?query are legal.

---

Of course, none of this provides a cast-iron guarantee that every web server or HTTP library will accept such URLs, nor that they will treat them as semantically equivalent to a URL that contains the slash. But as far as spec goes, skipping the slash is completely legal.

Answer 2

No. It is not correct to skip the slash. It may work modern browsers: however, that does not make it correct.

See RFC1738 - URL and RFC2396 - URI.

The format per RFC1738 (I have excluded the schema format here):

//<user>:<password>@<host>:<port>/<url-path>

And it goes on to note that:

...the "/" between the host (or port) and the url-path is NOT part of the url-path.

In this case the "?" is part of the url-path which

...depends on the scheme being used, as does the manner in which it is interpreted.

Also note that, per specification, it is perfectly valid to omit "/url-path" -- note that the "/" has been explicit included in this case.

Thus, "foo.com?bar" is invalid because there is no "/" before the url-path.

Answer 3

Adding to the accepted answer with some more information I found after researching this problem:

http://tools.ietf.org/html/rfc2396

The authority component is preceded by a double slash "//" and is terminated by the next slash "/", question-mark "?", or by the end of the URI. Within the authority component, the characters ";", ":", "@", "?", and "/" are reserved

Based on this statement, the question-mark should indicate the end of the authority component, with or without the slash.

http://tools.ietf.org/html/rfc1738 (tags replaced)

The {path} is optional, as is the {searchpart} and its preceding "?". If neither {path} nor {searchpart} is present, the "/" may also be omitted.

However, this statement says that the trailing slash can only be omitted if both the path and searchpart are not preset.

In the real world, I've previously been able to omit a trailing slash before a query value, but recently found a situation were that falls down. If you have a query such as this http://my.domain.com?do=something, and you view an html page in Internet Explorer, the link is fixed by IE. If you then click File, Send, Page by e-mail..., the link is added to the email with an invalid format. The issues vary by the content of the query value but we were able to create invalid URLs.

In summary, it should work, but falls down in edge cases.

Answer 4

It is not safe to assume that. Web servers and self-contained web applications typically inspect the URL provided in the request, but there is no guarantee that they will treat /abc equal to /abc/. Web servers and self-contained web applications can do whatever they like with the information gleaned from the URL, and it will not necessarily be what you expect. You will have to find out what the convention is for the particular URL in question.

Note, of course, that most web servers and web application frameworks try hard to accept all sorts of inputs and deal with them appropriately. Therefore, in most cases, the web server or self-contained web application will treat /abc equal to /abc/. But remember, because the server can do whatever it likes with the path, that this is simply a generic observation with potentially numerous exceptions.