Hi!
The main issue I'm not sure about here is the use
of ; as a query string
initiator (rather than a query string parameter separator). This use of
semicolons is completely non-standard, AFAIK, but it looks like there are
some web servers that are actually using it this way. Comments at the pull
request itself would be most useful (rather than by email).
Generally, the servers are free to parse the local part of the URL as
they like. After all, many servers using REST treat something like
/user/2/name as essentially query string, even though / is a path
separator. Nothing prevents other servers from adopting the scheme of
user;2;name instead or any other way of parsing the local path.
https://tools.ietf.org/html/rfc3986#section-3.4 clearly states that
query is delimited by "?". Which means the URLs with ";" are path
components, as per RFC:
Aside from dot-segments in hierarchical paths, a path segment is
considered opaque by the generic syntax. URI producing applications
often use the reserved characters allowed in a segment to delimit
scheme-specific or dereference-handler-specific subcomponents. For
example, the semicolon (";") and equals ("=") reserved characters
are
often used to delimit parameters and parameter values applicable to
that segment. The comma (",") reserved character is often used for
similar purposes. For example, one URI producer might use a segment
such as "name;v=1.1" to indicate a reference to version 1.1 of
"name", whereas another might use a segment such as "name,1.1" to
indicate the same.
So, the specific application can treat path components the same way as
query components, but they are still path components. My reading of the
RFC also seems to be that ";" is a reserved character, and as such
should not be URL-encoded. Indeed, path BNF includes sub-delims without
encoding, which includes ";". However, I am not sure I understand other
part of the patch where it plays with query string.
--
Stas Malyshev
smalyshev(a)wikimedia.org