Is a trailing ampersand legal in a URL?

A URL like

http://localhost/path?a=b&c=d

is fine - but what is the status of the same URL with a trailing ampersand?

htt开发者_运维技巧p://localhost/path?a=b&c=d&

For example the Java Servlet API allows it where Scala's Spray does not (ie it throws an error).

I've tried to find the answer in the URI syntax spec, but not sure how to parse their grammar.

---

The URI syntax spec is for generic URIs. It allows anything in the query. I am not aware of any specification which actually specifies ampersand-separated key=value pairs. I believe it is merely convention. I know that PHP, for example, offers an option for using a different separator. But now, everyone uses ampersand-separated things when they want key-value pairs. You still occasionally come across things which use it for just a simple string, e.g. http://example.com/?example. This is perfectly valid.

The basic answer, though, is that & is valid anywhere in the query string, including at the end.

---

Demistifying the RFC syntax, or Why & is valid anywhere in the query string:

First, you have

query       = *( pchar / "/" / "?" )

(So a query string is made of any number of pchar and literal slashes and question marks.)

Going back, you have

pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

And earlier still

sub-delims  = "!" / "$" / "&" / "'" / "(" / ")"
            / "*" / "+" / "," / ";" / "="

So a literal & is in sub-delims which is in pchar, so it's valid in query

---

I think there is an unwritten rule that all RFCs must be near impossible to understand. You're not the first person unable to parse the grammar and - in my humble opinion - Spray also failed too.

There is nothing wrong with a trailing ampersand. It is a legal character in the URI used to separate parameters. A trailing ampersand may be pointless, but it isn't invalid. Spray should (again, only in my opinion) be simply ignoring it.

---

If you have a url like the following in a plain-text email:

Please follow this link https://server/doc?param=test. to reset the password of your account.

It becomes a useful feature since if the last parameter ends with ". " (dot + space) and is placed in an e-mail, all kinds of mail clients assume that the dot is ending a sentence and exclude it from the clickable link they add if they detect a URL.

Putting the link between double-quotes or angle-brackets isn't supported in all mail clients and default URL encoding leaves the dot as it is not a reserved URI character...

I ended up appending a trailing ampersand "&" to the URL to fix this, call me crazy but it works.