More standard application/x-www-form-urlencoded parsing

[pauldraper]

• Allow semicolon separators in addition to ampersands
• Parse empty/non-existant names and values

---

W3C recommends accepting semicolons separators.

We recommend that HTTP server implementors, and in particular, CGI implementors support the use of ";" in place of "&"

Old stuff, but most parsers still follow the recommendation.

Also, most parsers accept empty names and values, and non-existent values. For example, the example request in RFC 5849 3.4.1.3.1 (OAuth 1.0) has the body

c2&a3=2+q

and requires parsing the c2 parameter in order for OAuth to work.

---

Most parsers allow these two usages, for example com.apache.http.client.utils.URLEncodedUtils or io.netty.handler.codec.http.QueryStringDecoder (HTML forms put fields in GET query strings, hence the name).

I would have used one of those rather than implementing it myself, but the play project doesn't currently depend on either.

[jroper]

Unlike splitting on a single character, splitting on a regular expression will parse/compile the regular expression on every invocation. It would be more performant to hold the regular expression in a val on an object and use it to split.

[pauldraper]

And OpenJDK doesn't cache regexes.....

I fixed this.

FYI, the library examples I mentioned go to the trouble of creating non-regex implementations.

[jroper]

Yeah, we can look at increasing performance if and when that's an issue. Another thing we should address is hashdos.

[benmccann]

@jroper looks like you were reviewing this one. what do you think? should we merge it?

[benmccann]

@jroper mind taking another look at this one?

[gmethvin]

This lgtm

[mkurz]

Ping @jroper