Hi all,
I'd like to propose these two changes below:
- Remove TSUrlHttpParamsGet/Set
- Remove special treatment for the "params" segment (not query parameters,
see below)
- Change TSUrlPathGet to include the "params" segment (as the result of the
removal of special treatment above)
RFC 1808 defined URL syntax as follows and it had "params".
<scheme>://<net_loc>/<path>;<params>?<query>#<fragment>
The syntax was updated on RFC 3986, and now semicolons do not have special
meanings in URL syntax. RFC 3986 says:
"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."
Since the path segment is opaque, only applications can understand the
structure. In fact, there are applications that use semicolons not only in
between "path" and "query" but also at random places in the "path" segment.
For example, "/abc;p1=x/def;p2=y/ghi". Some people call this Matrix
Parameters. Although there seems to be common sense in the way of embedding
parameters into the "path" segment, it's not really standardized (please
let me know if there is a specification, but not blog posts). It is
impossible to support all the variations of Matrix Parameters syntaxes.
ATS has TSUrlHttpParamsGet which is supposed to return the "params" segment
defined on RFC 1808, but the implementation is incomplete (there are
patterns that can not be parsed correctly). And needless to say, it does
not support Matrix Parameters.
I think ATS should drop the support for the "params" segment because it's
no longer defined on RFCs and TSUrlHttpParamsGet does not satisfy anyone's
expectations properly. Moreover, the existence of TSUrlHttpParamsGet is
error prone because some people don't expect there is such a segment.
The changes I proposed above would be made in 2 steps.
Step 1 (ATS 10):
- Mark TSUrlHttpParamsGet as deprecated
- Make TSUrlHttpParamsGet return empty string
- Remove code for the "params" segment (i.e. the code that searches a
semicolon, etc)
- Make TSUrlPathGet include the "params" segment which is currently
returned by TSUrlHttpParamsGet
Step 2 (ATS 11 or later):
- Remove TSUrlHttpParamsGet
In step 1, there should be no negative impact to existing plugins. Existing
code should work without any code changes. Some plugins that use
TSUrlPathGet might work a bit differently because the API would include the
string between a semicolon and a question mark, but such plugins might have
been working incorrectly because of the incomplete implementation of the
URL parser.
Thoughts?
Thanks,
Masakazu
