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. >>>>> >>> >>>
