I'm wondering if we should add this template to our core utilities:
https://godbolt.org/z/4X-5wR . We could use it to conduct a gradual
campaign of "creeping encapsulation", to pull up the pants of our many
classes with (often lots of) public data members. If a class X had the
data member 'int xy
That was the original version of the PR, to just change the behavior of the
existing effective URL get function. It just twisted in the wind for two
months.
I think an aversion to long names in a C API is not realistic. When ya got
no scoping or overloading, it's either long names or very unintu
Any +1's for simply replacing TSDebug with the proposed TSFastDbg ?
On Mon, Apr 8, 2019 at 6:20 PM Leif Hedstrom wrote:
>
>
> On Apr 4, 2019, at 8:05 AM, Walt Karas
> wrote:
>
> Because senility. probably "on" should be a non-pointer of type const
> volatile char, and InkAPI in the core can jus
> On Jun 11, 2019, at 12:24 PM, Walt Karas
> 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 an
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 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 wrote:
> What are you matching against? Are you trying to match against the URL of
> a previous request? Why only no
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 ac
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
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 underst
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.
10 matches
Mail list logo
