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...@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
