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