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