URL 中的尾随 & 符号是否合法？

Question

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.

Answer 1

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, eg 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

Answer 2

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.

Answer 3

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.