I meant wouldn’t in the last sentence. :)
-Bryan
> On Jun 12, 2019, at 9:47 AM, Bryan Call 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 lowerc
> On Jun 12, 2019, at 10:47 AM, Bryan Call 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
> d
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.
-Bryan
>
When I dived into the code it looks like this is separate code from generating
the cache key.
Cache::generate_key > URL::hash_get() > url_CryptoHash_get()
Vs
TSHttpTxnEffectiveNormalizedUrlStringGet() > HTTPHdr::url_string_get()
-Bryan
> On Jun 12, 2019, at 7:09 AM, Sudheer Vinukonda
> wr
That sounds reasonable. However, it does cause a compatibility issue for
someone upgrading in that, I think this API might change the cache key and
could potentially break cache.
Given that, wouldn’t we prefer to break the API in a more obvious fashion (e.g.
modify the signature to require a “
Didn't that PR do the normalization at a lower level? I like zwoop's idea,
that TSEffectiveUrlGet always return a normalized URL. It's kind of the
point of the call, to get the "real" URL from the request. I don't even
think that breaks compatibility since that's the correct value to return.
On Tu
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
> 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.
> On Jun 10, 2019, at 21:38, Sudheer Vinukonda
> wrote:
>
> Can you describe the use cases for needing this API?
>
> Also, why can’t the caller normalise the url returned by
> TSHttpTxnEffectiveUrlStringGet()? It appears like an “overload” to support an
> API just for normalisation alone,
Can you describe the use cases for needing this API?
Also, why can’t the caller normalise the url returned by
TSHttpTxnEffectiveUrlStringGet()? It appears like an “overload” to support an
API just for normalisation alone, unless I’m missing something.
- Sudheer
> On Jun 10, 2019, at 6:26 PM,
In https://github.com/apache/trafficserver/pull/5217 .
Same as TSHttpTxnEffectiveUrlStringGet(), but make sure scheme and host are
normalized to all lower case letters.
17 matches
Mail list logo
