Also what’s the semantic here when both http:// and https:// URLs map to the
same cached object ? The first cached request specifies the scheme? This seems
confusing at best... or are we talking about the scheme as it goes to origin
(which would have to be the same for both).
Seems like a rema
The point here being to make a new API that replaces the old, without breaking
compatibility? And this new API has special semantics on a cache hit vs cache
miss?
This seems pretty convoluted, making it difficult for plugin writers to use the
right API...
— Leif
> On Sep 28, 2020, at 19:49,
+1
Traffic Dump can make use of this.
On Mon, Sep 28, 2020 at 7:38 PM Walt Karas
wrote:
> This should get the scheme for the request. This differs from
> `TSUrlSchemeGet` in that it gets the scheme even if it is not in the URL of
> the request. For most proxy requests, the ATS core will remove
This should get the scheme for the request. This differs from
`TSUrlSchemeGet` in that it gets the scheme even if it is not in the URL of
the request. For most proxy requests, the ATS core will remove the host and
scheme in the request while tracking it internally. In such a case a plugin
cannot di
Yes, that makes sense, if you are reading the var name and value from a
JSON/YAML config file, you might want to accept an integral value for a
float var, without causing an error. I was just wondering if Dr. Zret had
other uses in mind.
On Mon, Sep 28, 2020 at 5:07 PM Damian Meden
wrote:
> > f
> for example, the name is passed as a plugin parameter or in a
plugin config file?
yes, that could be an example in my pov. Now, I will not speak about
TxnBox, but in in general unless you know the type of the record you will
not get the right value, AFAICT, currently if you request for a `string
You mean, for example, the name is passed as a plugin parameter or in a
plugin config file? Is this for txn box? Is it obvious to everyone but me
that a use for this will come up?
On Mon, Sep 28, 2020 at 3:59 PM Alan Carroll
wrote:
> No, it's for handling cases where the configuration variable
No, it's for handling cases where the configuration variable name is not
known at compile time.
On Mon, Sep 28, 2020 at 3:46 PM Walt Karas
wrote:
> So, more concretely, is it for future safety? For example, if the value is
> a percentage, and it's currently an int, but you suspect it may need t
So, more concretely, is it for future safety? For example, if the value is
a percentage, and it's currently an int, but you suspect it may need to
become a float?
On Mon, Sep 28, 2020 at 2:43 PM Alan Carroll
wrote:
> Suppose you want to fetch a configuration value, and want to know whether
> to
Suppose you want to fetch a configuration value, and want to know whether
to call TSMgmtIntGet or *TSMgmtFloatGet*. There is currently no way to know
programmatically. The code has to "just know" which it is.
On Mon, Sep 28, 2020 at 2:10 PM Walt Karas
wrote:
> Can you describe an example situati
Can you describe an example situation where this would be useful?
On Mon, Sep 28, 2020 at 1:59 PM Damian Meden
wrote:
> Hi Guys.
>
> I would like to propose adding a new API function to bring the record data
> type from a particular record.
>
> A brief description of this new proposed API:
>
>
>
Hi Guys.
I would like to propose adding a new API function to bring the record data
type from a particular record.
A brief description of this new proposed API:
*TSReturnCode TSMgmtDataTypeGet(const char
* var_name, TSRecordDataType * result)*
Get the type of a value for a configuration variab
12 matches
Mail list logo
