One week of silence. I assume the proposal was accepted.
I made a PR for this change.
https://github.com/apache/trafficserver/pull/11519
Thanks,
Masakazu
On Mon, Jul 1, 2024 at 10:21 PM Masakazu Kitajo <mas...@apache.org> wrote:
> 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
>
>
