Reputation: 9498
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?
http://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.
Upvotes: 27
Views: 7222
Reputation: 2288
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.
Upvotes: -1
Reputation: 90742
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
Upvotes: 29
Reputation: 33094
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.
Upvotes: 9