Looks mostly good to me, except a minor coding issue. The API documentation
is on that PR as well, anyone who is concerned should look at it. I think
it avoids the issues that have been brought up on this exchange.
On Tue, Feb 20, 2018 at 5:52 PM, Walt Karas wrote:
> I've issued a pull request f
I've issued a pull request for the implementation of this:
https://github.com/apache/trafficserver/pull/3145
On Thu, Feb 1, 2018 at 12:49 PM, Leif Hedstrom wrote:
>
>
>> On Feb 1, 2018, at 9:35 AM, Alan Carroll
>> wrote:
>>
>> That's a good suggestion, although shouldn't it be
>>
>> TSReturnCo
> On Feb 1, 2018, at 9:35 AM, Alan Carroll
> wrote:
>
> That's a good suggestion, although shouldn't it be
>
> TSReturnCode TSRemapFromUrlGet(TSHttpTxn txnp, TSMBuffer bufp, TSMLoc* obj);
>
> That is the TSMLoc should be an out parameter, not an in. In that case I'd
> drop the ...StringGet()
When calling this, where would the value for the bufp parameter come
from? How would it be used in the implementation?
On Thu, Feb 1, 2018 at 10:35 AM, Alan Carroll
wrote:
> That's a good suggestion, although shouldn't it be
>
> TSReturnCode TSRemapFromUrlGet(TSHttpTxn txnp, TSMBuffer bufp, TSML
That's a good suggestion, although shouldn't it be
TSReturnCode TSRemapFromUrlGet(TSHttpTxn txnp, TSMBuffer bufp, TSMLoc* obj);
That is the TSMLoc should be an out parameter, not an in. In that case I'd
drop the ...StringGet() and use the generic TSUrlStringGet() if a string is
needed.
> On Jan 30, 2018, at 9:15 AM, Walt Karas wrote:
>
> Revised:
>
> const char *TSRemapFromUrlStringGet(const TSHttpTxn txnp, int &length);
>
> const char *TSRemapToUrlStringGet(const TSHttpTxn txnp, int &length);
>
> These would return, from the transaction state object,
> url_map.getFromURL(
This is intended primarily for use by XDebug and operationally it would be
infeasible to add that plugin to every remap rule in order to access those
values.
> On Jan 31, 2018, at 4:33 PM, Leif Hedstrom wrote:
>
>
>
>> On Jan 29, 2018, at 11:02 AM, Walt Karas wrote:
>>
>> const char *TSIRemapFromUrlStringGet(const TSHttpTxn txnp);
>>
>> const char *TSIRemapToUrlStringGet(const TSHttpTxn txnp);
>>
>> These would return, from the transaction sta
> On Jan 29, 2018, at 11:02 AM, Walt Karas wrote:
>
> const char *TSIRemapFromUrlStringGet(const TSHttpTxn txnp);
>
> const char *TSIRemapToUrlStringGet(const TSHttpTxn txnp);
>
> These would return, from the transaction state object,
> url_map.getFromURL() and url_map.getToURL() respectively
I've done a preliminary implementation, based on the version that
returns the URLs as strings:
https://github.com/ywkaras/trafficserver/pull/4
On Tue, Jan 30, 2018 at 6:04 PM, Walt Karas wrote:
> Another alternative is to get handles to the "binary" URLs:
>
> TSReturnCode TSRemapFromUrlGet(TSHtt
Another alternative is to get handles to the "binary" URLs:
TSReturnCode TSRemapFromUrlGet(TSHttpTxn txnp, TSMLoc *url_loc);
TSReturnCode TSRemapToUrlGet(TSHttpTxn txnp, TSMLoc *url_loc);
These would return, from the transaction object state, handles for
url_map.getFromURL() and url_map.getToURL
I meant this
On Tue, Jan 30, 2018 at 11:15 AM, Walt Karas
wrote:
> Revised:
> (Nul-termination
> should not be expected/presumed.) .
vs.
> On Mon, Jan 29, 2018 at 4:55 PM, Walt Karas wrote:
> > The plugin would own them and would have to call TSFree() when done
> > with them. They would be
Sorry you lost me. The revision superceeds the prior mail I sent, if
that's what you mean by "API write up". I tried to change it to
follow the pattern of TSUrlStringGet(), which I think does not
nul-terminate.
On Tue, Jan 30, 2018 at 12:47 PM, Alan Carroll
wrote:
> May I presume your API write
May I presume your API write up, not your previous reply, is correct with
regard to null termination of the string?
Revised:
const char *TSRemapFromUrlStringGet(const TSHttpTxn txnp, int &length);
const char *TSRemapToUrlStringGet(const TSHttpTxn txnp, int &length);
These would return, from the transaction state object,
url_map.getFromURL() and url_map.getToURL() respectively, in strong
format. A null pointe
The plugin would own them and would have to call TSFree() when done
with them. They would be nul terminated.
On Mon, Jan 29, 2018 at 4:52 PM, Alan Carroll
wrote:
> What are the ownership properties of the memory indicated by the returned
> pointers? Are these strings guaranteed to be null termin
Sorry that's a typo, it should not be there.
On Mon, Jan 29, 2018 at 3:53 PM, Shu Kit Chan wrote:
> What does the "I" stand for in "TSIRemapFromUrlStringGet" ?
>
> On Mon, Jan 29, 2018 at 10:02 AM, Walt Karas wrote:
>> const char *TSIRemapFromUrlStringGet(const TSHttpTxn txnp);
>>
>> const char
What are the ownership properties of the memory indicated by the returned
pointers? Are these strings guaranteed to be null terminated or is a length
needed?
On Mon, Jan 29, 2018 at 3:53 PM, Shu Kit Chan wrote:
> What does the "I" stand for in "TSIRemapFromUrlStringGet" ?
>
> On Mon, Jan 29, 201
What does the "I" stand for in "TSIRemapFromUrlStringGet" ?
On Mon, Jan 29, 2018 at 10:02 AM, Walt Karas wrote:
> const char *TSIRemapFromUrlStringGet(const TSHttpTxn txnp);
>
> const char *TSIRemapToUrlStringGet(const TSHttpTxn txnp);
>
> These would return, from the transaction state object,
>
19 matches
Mail list logo
