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