> On Jun 12, 2019, at 10: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.
>
For cache keys, we should have reasonable defaults (and it’s difficult to
change those defaults, ever, so we’re pretty much SOL on modifying those). For
all other custom needs, I firmly believe it belongs in the cachekey plugin. It
can control whatever normalization (case sensitive, query param ordering etc.
etc. that you need).
Cheers,
— Leif
> -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.
>>>>>>
>>>>
>>>>
>
