It should be possible to call a URL like:
GET /foo?bar%26baz=tom%26jerry
With the desired result being that the application gets a query-parameter with name bar&baz and value tom&jerry.
(%26 is the url percent-encoding for &)
This is not possible in CCF, because we do an early-decode of the query as a single string, so we convert to bar&baz=tom&jerry before we try to split-at-ampersands. This was a plausibly generic approach (because the ampersand-separated key=value format is a mere universal pattern, rather than part of the original URL spec), that prevented apps having to url_decode everything at the last-minute. But it means this (unconventional, but plausibly app-desired) query parameter is disallowed by the framework.
Options:
- Document that this is explicitly not supported.
- Store the raw query without decoding, and document that it should be manually parsed if you want to support this.
- Do an early, smarter query parse (split at &, then at =, then decode key and value) rather than leaving a decoded query string. This is probably the right (helpful) thing to do, but is a slightly awkward API inflation.
It should be possible to call a URL like:
With the desired result being that the application gets a query-parameter with name
bar&bazand valuetom&jerry.(
%26is the url percent-encoding for&)This is not possible in CCF, because we do an early-decode of the
queryas a single string, so we convert tobar&baz=tom&jerrybefore we try to split-at-ampersands. This was a plausibly generic approach (because the ampersand-separated key=value format is a mere universal pattern, rather than part of the original URL spec), that prevented apps having tourl_decodeeverything at the last-minute. But it means this (unconventional, but plausibly app-desired) query parameter is disallowed by the framework.Options: