On Aug 16, 2014, at 8:17 PM, portl4t...@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...@gmail.com
>
>
> 在 2014年8月17日 星期日，上午9:32，James Peach 写道：
>
>> On Aug 16, 2014, at 5:55 PM, portl4t...@gmail.com
>> (mailto:portl4t...@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...@gmail.com (mailto:portl4t...@gmail.com)
>>>
>>>
>>> 在 2014年8月16日 星期六，上午4:55，James Peach 写道：
>>>
>>>> On Aug 15, 2014, at 10:23 AM, Alan M. Carroll
>>>> <a...@network-geographics.com (mailto:a...@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
>
