You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by po...@gmail.com on 2014/08/17 02:55:28 UTC
回复： TSMimeHdrFieldNext
I use this api heavily, I think we have to iterate over all headers if we want to create FetchSM.
I use this api in some plugins, such as Combo, ESI, Slice and so on.
Every time if we want to intercept the HttpSM and create several FetchSM to construct the real response, this api will be used.
--
portl4t.cn@gmail.com
在 2014年8月16日 星期六，上午4:55，James Peach 写道：
> On Aug 15, 2014, at 10:23 AM, Alan M. Carroll <amc@network-geographics.com (mailto:amc@network-geographics.com)> wrote:
>
> > This came up yesterday on the IRC. The problem is that every call to TSMimeHdrFieldNext allocates a MIME field handle which gets very slow if you use the function heavily. One suggested approach was to switch the allocator from a global to a per thread.
> >
> > I think it might be better to add TSMimeHdrFieldHandleNext() which updates the MIME field handle in place. Does this seem like a reasonable API addition?
>
> What's a real use case for iterating over all the headers?
>
> J
Re: 回复： TSMimeHdrFieldNext
Posted by Leif Hedstrom <zw...@apache.org>.
On Aug 16, 2014, at 8:17 PM, portl4t.cn@gmail.com wrote:
> I think we have to create FetchSM with all the headers from the client request, should not we?
> Is there any other way to get all the headers from the client request?
Yes, there is a way to “dump” all headers on a VIO, would that not work with the FetchSM? In e.g. background_fetch, we do
if ((data->vc = TSHttpConnect((sockaddr*)&data->client_ip)) != NULL) {
TSHttpHdrPrint(data->mbuf, data->hdr_loc, data->req_io_buf);
// We never send a body with the request. ToDo: Do we ever need to support that ?
TSIOBufferWrite(data->req_io_buf, "\r\n", 2);
I.e. TSHttpHdrPrint( …);
— Leif
>
>
> --
> portl4t.cn@gmail.com
>
>
> 在 2014年8月17日 星期日，上午9:32，James Peach 写道：
>
>> On Aug 16, 2014, at 5:55 PM, portl4t.cn@gmail.com (mailto:portl4t.cn@gmail.com) wrote:
>>
>>> I use this api heavily, I think we have to iterate over all headers if we want to create FetchSM.
>>
>> Why? To serialize the mime headers?
>>
>>> I use this api in some plugins, such as Combo, ESI, Slice and so on.
>>> Every time if we want to intercept the HttpSM and create several FetchSM to construct the real response, this api will be used.
>>>
>>>
>>> --
>>> portl4t.cn@gmail.com (mailto:portl4t.cn@gmail.com)
>>>
>>>
>>> 在 2014年8月16日 星期六，上午4:55，James Peach 写道：
>>>
>>>> On Aug 15, 2014, at 10:23 AM, Alan M. Carroll <amc@network-geographics.com (mailto:amc@network-geographics.com)> wrote:
>>>>
>>>>> This came up yesterday on the IRC. The problem is that every call to TSMimeHdrFieldNext allocates a MIME field handle which gets very slow if you use the function heavily. One suggested approach was to switch the allocator from a global to a per thread.
>>>>>
>>>>> I think it might be better to add TSMimeHdrFieldHandleNext() which updates the MIME field handle in place. Does this seem like a reasonable API addition?
>>>>
>>>> What's a real use case for iterating over all the headers?
>>>>
>>>> J
>
回复： TSMimeHdrFieldNext
Posted by po...@gmail.com.
I think we have to create FetchSM with all the headers from the client request, should not we?
Is there any other way to get all the headers from the client request?
--
portl4t.cn@gmail.com
在 2014年8月17日 星期日，上午9:32，James Peach 写道：
> On Aug 16, 2014, at 5:55 PM, portl4t.cn@gmail.com (mailto:portl4t.cn@gmail.com) wrote:
>
> > I use this api heavily, I think we have to iterate over all headers if we want to create FetchSM.
>
> Why? To serialize the mime headers?
>
> > I use this api in some plugins, such as Combo, ESI, Slice and so on.
> > Every time if we want to intercept the HttpSM and create several FetchSM to construct the real response, this api will be used.
> >
> >
> > --
> > portl4t.cn@gmail.com (mailto:portl4t.cn@gmail.com)
> >
> >
> > 在 2014年8月16日 星期六，上午4:55，James Peach 写道：
> >
> > > On Aug 15, 2014, at 10:23 AM, Alan M. Carroll <amc@network-geographics.com (mailto:amc@network-geographics.com)> wrote:
> > >
> > > > This came up yesterday on the IRC. The problem is that every call to TSMimeHdrFieldNext allocates a MIME field handle which gets very slow if you use the function heavily. One suggested approach was to switch the allocator from a global to a per thread.
> > > >
> > > > I think it might be better to add TSMimeHdrFieldHandleNext() which updates the MIME field handle in place. Does this seem like a reasonable API addition?
> > >
> > > What's a real use case for iterating over all the headers?
> > >
> > > J
Re: 回复： TSMimeHdrFieldNext
Posted by James Peach <jp...@apache.org>.
On Aug 16, 2014, at 5:55 PM, portl4t.cn@gmail.com wrote:
> I use this api heavily, I think we have to iterate over all headers if we want to create FetchSM.
Why? To serialize the mime headers?
> I use this api in some plugins, such as Combo, ESI, Slice and so on.
> Every time if we want to intercept the HttpSM and create several FetchSM to construct the real response, this api will be used.
>
>
> --
> portl4t.cn@gmail.com
>
>
> 在 2014年8月16日 星期六，上午4:55，James Peach 写道：
>
>> On Aug 15, 2014, at 10:23 AM, Alan M. Carroll <amc@network-geographics.com (mailto:amc@network-geographics.com)> wrote:
>>
>>> This came up yesterday on the IRC. The problem is that every call to TSMimeHdrFieldNext allocates a MIME field handle which gets very slow if you use the function heavily. One suggested approach was to switch the allocator from a global to a per thread.
>>>
>>> I think it might be better to add TSMimeHdrFieldHandleNext() which updates the MIME field handle in place. Does this seem like a reasonable API addition?
>>
>> What's a real use case for iterating over all the headers?
>>
>> J
>