Didn't that PR do the normalization at a lower level? I like zwoop's idea, that TSEffectiveUrlGet always return a normalized URL. It's kind of the point of the call, to get the "real" URL from the request. I don't even think that breaks compatibility since that's the correct value to return.
On Tue, Jun 11, 2019 at 3:33 PM Walt Karas <wka...@verizonmedia.com.invalid> wrote: > That was the original version of the PR, to just change the behavior of the > existing effective URL get function. It just twisted in the wind for two > months. > > I think an aversion to long names in a C API is not realistic. When ya got > no scoping or overloading, it's either long names or very unintuitive ones. > > > On Tue, Jun 11, 2019 at 3:03 PM Leif Hedstrom <zw...@apache.org> wrote: > > > > > > > > On Jun 11, 2019, at 12:24 PM, Walt Karas <wka...@verizonmedia.com > .INVALID> > > wrote: > > > > > > Sorry, premature send, my Mac sucks, fix it zwoop. > > > > > > I looked and the IETF specs and discussed it with Dave Thompson. It > > seems > > > that the only parts of the URL/URI that the Standards require to be > case > > > insensitive are the scheme and the host. Our plugin compares the URL > > with > > > a simple string compare. I think, for the purposes of that plugin, all > > > other parts of the URL are case sensitive. I'd rather not have to > change > > > the plugin to have to deal with each component of the effective URL > > > individually. Of course, this is probably just a fail safe, I would > bet > > > $10 that the widely used browsers normalize the scheme and host to > > > lowercase anyway. > > > > > > Seems we could normalize those two fields in the existing API then. If > > that is an expected behavior (which I think both Walt and amc are > > implying), then why have an option to open up confusion. This would be > > inline with amc’s argument as well, that leaving normalization as an > option > > opens up a can of worm. So just always do the same thing, and everyone is > > happy (i don’t think we need two APIs for this). > > > > Alternatively, we can change the existing API to take a normalization > > option, and break compatibility. I much prefer either of these options > than > > adding this really convoluted API contraption. > > > > — Leif > > > > > > > > On Tue, Jun 11, 2019 at 1:18 PM Walt Karas <wka...@verizonmedia.com> > > wrote: > > > > > >> I looked and the IETF specs and discussed it with Dave Thompson. It > > seems > > >> that the only parts of the URL/URI that the Standards requ > > >> > > >> On Tue, Jun 11, 2019 at 12:59 PM Bryan Call <bc...@apache.org> wrote: > > >> > > >>> What are you matching against? Are you trying to match against the > URL > > >>> of a previous request? Why only normalize the scheme and host and > not > > the > > >>> path, query parameters, or matrix parameters? > > >>> > > >>> I think the problem is you are not giving details and people are > > guessing > > >>> at what you are trying to accomplish. > > >>> > > >>> -Bryan > > >>> > > >>> > > >>>> On Jun 11, 2019, at 10:14 AM, Walt Karas <wka...@verizonmedia.com > > .INVALID> > > >>> wrote: > > >>>> > > >>>> We (Verizon) want to deploy a plugin that matches on URL premap. > With > > >>> the > > >>>> host and scheme normalized, we can do the matching using a simple > > string > > >>>> compare. I had put up a PR to simply change the behavior of > > >>>> TSHttpTxnEffectiveUrlStringGet() but it was pocket vetoed by lack of > > >>>> reviews. > > >>>> > > >>>> On Tue, Jun 11, 2019 at 12:03 PM Sudheer Vinukonda > > >>>> <sudheervinuko...@yahoo.com.invalid> wrote: > > >>>> > > >>>>> Hmm..But, how do you define "correct" normalization? Wouldn't that > be > > >>> use > > >>>>> case specific? Which is exactly why it feels like this shouldn't be > > >>> done in > > >>>>> the core? > > >>>>> If the use case is a common one that benefits everyone, then there > > >>> might > > >>>>> still be value in supporting it. That's why, curious to understand > > the > > >>> use > > >>>>> case. > > >>>>> On Tuesday, June 11, 2019, 8:49:24 AM PDT, Alan Carroll > > >>>>> <solidwallofc...@verizonmedia.com.INVALID> wrote: > > >>>>> > > >>>>> The issue is, what is the correct normalization to perform? If > that's > > >>>>> non-trivial, there's an argument for embedding that in the API > > rather > > >>> than > > >>>>> requiring every plugin to hand roll it. It would be the same reason > > >>>>> `realpath` exists. > > >>>>> > > >>> > > >>> > > > > >
