You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Walt Karas <wk...@oath.com.INVALID> on 2018/09/12 23:52:43 UTC
Headers.h in the CPPAPI
Who has used this and what issues (if any) have you had with it?
Re: Headers.h in the CPPAPI
Posted by Walt Karas <wk...@oath.com.INVALID>.
I don't understand.
What does "pointer from a TSMLoc" mean? How can the TSMLoc still be
valid but not be safe?
On Mon, Sep 17, 2018 at 2:35 PM, Alan Carroll
<so...@oath.com.invalid> wrote:
> No, the TSMLoc should still be valid. That's the point of requiring using
> TSMLoc. Internally it does a pointer indirection so the pointer can
> updated. What's not safe is any pointer from a TSMLoc.
>
> On Thu, Sep 13, 2018 at 8:48 PM CrazyCow <zh...@gmail.com> wrote:
>
>> read, delete, etc.
>> If you can share some pseudo code having the issue, we can analyze it to
>> see if it's a design issue or being used in a wrong way.
>>
>> Walt Karas <wk...@oath.com.invalid> 于2018年9月13日周四 上午8:21写道：
>>
>> > Do you use it to change the contents of headers or just to read them?
>> >
>> > I've been told that if (for example) you get the TSMLoc for two
>> > header fields, and then change or delete the second field, this may
>> > cause the first TSMLoc to become a dangling pointer. It doesn't look
>> > like the Header.h code handles this possibility.
>> >
>> > On Wed, Sep 12, 2018 at 7:55 PM, zzz <zz...@apache.org> wrote:
>> > > Linkedin Traffic team is actively using it. It's quite handy.
>> > > (Thanks @bgeffon
>> > > One issue we found so far is Headers.wireStr() is much slower than the
>> > raw
>> > > API equivalent TSMimeHdrPrint, so you've better to avoid that.
>> > >
>> > > Walt Karas <wk...@oath.com.invalid> 于2018年9月12日周三 下午4:52写道：
>> > >
>> > >> Who has used this and what issues (if any) have you had with it?
>> > >>
>> >
>>
>
>
> --
> *Beware the fisherman who's casting out his line in to a dried up riverbed.*
> *Oh don't try to tell him 'cause he won't believe. Throw some bread to the
> ducks instead.*
> *It's easier that way. *- Genesis : Duke : VI 25-28
Re: Headers.h in the CPPAPI
Posted by Alan Carroll <so...@oath.com.INVALID>.
No, the TSMLoc should still be valid. That's the point of requiring using
TSMLoc. Internally it does a pointer indirection so the pointer can
updated. What's not safe is any pointer from a TSMLoc.
On Thu, Sep 13, 2018 at 8:48 PM CrazyCow <zh...@gmail.com> wrote:
> read, delete, etc.
> If you can share some pseudo code having the issue, we can analyze it to
> see if it's a design issue or being used in a wrong way.
>
> Walt Karas <wk...@oath.com.invalid> 于2018年9月13日周四 上午8:21写道：
>
> > Do you use it to change the contents of headers or just to read them?
> >
> > I've been told that if (for example) you get the TSMLoc for two
> > header fields, and then change or delete the second field, this may
> > cause the first TSMLoc to become a dangling pointer. It doesn't look
> > like the Header.h code handles this possibility.
> >
> > On Wed, Sep 12, 2018 at 7:55 PM, zzz <zz...@apache.org> wrote:
> > > Linkedin Traffic team is actively using it. It's quite handy.
> > > (Thanks @bgeffon
> > > One issue we found so far is Headers.wireStr() is much slower than the
> > raw
> > > API equivalent TSMimeHdrPrint, so you've better to avoid that.
> > >
> > > Walt Karas <wk...@oath.com.invalid> 于2018年9月12日周三 下午4:52写道：
> > >
> > >> Who has used this and what issues (if any) have you had with it?
> > >>
> >
>
--
*Beware the fisherman who's casting out his line in to a dried up riverbed.*
*Oh don't try to tell him 'cause he won't believe. Throw some bread to the
ducks instead.*
*It's easier that way. *- Genesis : Duke : VI 25-28
Re: Headers.h in the CPPAPI
Posted by CrazyCow <zh...@gmail.com>.
read, delete, etc.
If you can share some pseudo code having the issue, we can analyze it to
see if it's a design issue or being used in a wrong way.
Walt Karas <wk...@oath.com.invalid> 于2018年9月13日周四 上午8:21写道：
> Do you use it to change the contents of headers or just to read them?
>
> I've been told that if (for example) you get the TSMLoc for two
> header fields, and then change or delete the second field, this may
> cause the first TSMLoc to become a dangling pointer. It doesn't look
> like the Header.h code handles this possibility.
>
> On Wed, Sep 12, 2018 at 7:55 PM, zzz <zz...@apache.org> wrote:
> > Linkedin Traffic team is actively using it. It's quite handy.
> > (Thanks @bgeffon
> > One issue we found so far is Headers.wireStr() is much slower than the
> raw
> > API equivalent TSMimeHdrPrint, so you've better to avoid that.
> >
> > Walt Karas <wk...@oath.com.invalid> 于2018年9月12日周三 下午4:52写道：
> >
> >> Who has used this and what issues (if any) have you had with it?
> >>
>
Re: Headers.h in the CPPAPI
Posted by Walt Karas <wk...@oath.com.INVALID>.
Do you use it to change the contents of headers or just to read them?
I've been told that if (for example) you get the TSMLoc for two
header fields, and then change or delete the second field, this may
cause the first TSMLoc to become a dangling pointer. It doesn't look
like the Header.h code handles this possibility.
On Wed, Sep 12, 2018 at 7:55 PM, zzz <zz...@apache.org> wrote:
> Linkedin Traffic team is actively using it. It's quite handy.
> (Thanks @bgeffon
> One issue we found so far is Headers.wireStr() is much slower than the raw
> API equivalent TSMimeHdrPrint, so you've better to avoid that.
>
> Walt Karas <wk...@oath.com.invalid> 于2018年9月12日周三 下午4:52写道：
>
>> Who has used this and what issues (if any) have you had with it?
>>
Re: Headers.h in the CPPAPI
Posted by zzz <zz...@apache.org>.
Linkedin Traffic team is actively using it. It's quite handy.
(Thanks @bgeffon
One issue we found so far is Headers.wireStr() is much slower than the raw
API equivalent TSMimeHdrPrint, so you've better to avoid that.
Walt Karas <wk...@oath.com.invalid> 于2018年9月12日周三 下午4:52写道：
> Who has used this and what issues (if any) have you had with it?
>