I meant wouldn’t in the last sentence. :) -Bryan
> On Jun 12, 2019, at 9:47 AM, Bryan Call <bc...@apache.org> wrote: > > The RFC isn’t clear on what can be normalized for generating cache keys. In > practice I have done other methods for normalizing URLs such as sorting query > parameters. I have also lowercased paths knowing that the origin would be > doing the same, which I would recommend in this case. > > -Bryan > > >> On Jun 11, 2019, at 11:24 AM, 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. >> >> 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. >>>>>> >>>> >>>> >
