On Aug 16, 2014, at 7:35 PM, James Peach wrote:
> On Aug 16, 2014, at 8:29 AM, Brian Geffon wrote:
>
>> I'm definitely +1 for functor/iterator semantics, ideally it could be done
>> in such a way as to preserve backwards compatability.
>
> My initial reaction is against a callback-based API b
On Aug 16, 2014, at 8:29 AM, Brian Geffon wrote:
> I'm definitely +1 for functor/iterator semantics, ideally it could be done
> in such a way as to preserve backwards compatability.
My initial reaction is against a callback-based API because that's not
consistent with the existing API patterns.
I think there are two reasonable approaches -
1) Iterator style. In this case we either create a new iterator type or re-use
the FieldHandle as an iterator. In this case you get a handle to the first
field, and then re-use it for each field. This saves the expense of allocating
a new handle for
On Aug 15, 2014, at 3:13 PM, Nick Kew wrote:
>
> On 15 Aug 2014, at 21:55, James Peach wrote:
>
>> What's a real use case for iterating over all the headers?
>
> Ironbee. Or any WAF, or WAF framework.
ah, waf and header whitelisting makes sense
>
> Or performance analysis tools.
>
> --
>
I'm definitely +1 for functor/iterator semantics, ideally it could be done
in such a way as to preserve backwards compatability.
On Aug 16, 2014 10:35 PM, "Leif Hedstrom" wrote:
> I have some mixed feeling on this. Such as, is us TSMimeHdrFieldGet a
> better candidate to improve for looping over
I have some mixed feeling on this. Such as, is us TSMimeHdrFieldGet a better
candidate to improve for looping over all fields ? Or even a new API with
functor semantics?
TSMimeHdrFieldGet at least avoids one loop to avoid finding the slotnum
> On Aug 16, 2014, at 5:29 AM, Brian Geffon wrote:
>
If no one has already started on a fix I can take this.
Brian
On Aug 16, 2014 6:13 AM, "Nick Kew" wrote:
>
> On 15 Aug 2014, at 21:55, James Peach wrote:
>
> > What's a real use case for iterating over all the headers?
>
> Ironbee. Or any WAF, or WAF framework.
>
> Or performance analysis tools
On 15 Aug 2014, at 21:55, James Peach wrote:
> What's a real use case for iterating over all the headers?
Ironbee. Or any WAF, or WAF framework.
Or performance analysis tools.
--
Nick Kew
It may be sometimes useful/required to check (or even modify) every header
in the request.
For example, one of the use cases we have is to allow only white listed
headers in the response and strip off the others.
Another use case is related to SPDY client connections, where some older
origins do
On Aug 15, 2014, at 10:23 AM, Alan M. Carroll
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 gl
Leif,
> But if the goal is to always iterate over all headers, I’m guessing (but not
> sure?) that it could be done more efficiently with an API that assumes so ?
> But alas, I don’t know what the use case here is, I’ve yet to see one where
> iterating over all headers is required (you usually
On Aug 15, 2014, at 12:33 PM, Alan M. Carroll
wrote:
> Leif,
>
>> Is the goal here to iterate over all headers? If so, maybe some sort of
>> iterator functionality would be more appropriate, similar to how we added
>> the iterator (with a callback) for lib records (i.e. TSRecordDump() )? Can
On Aug 15, 2014, at 12:33 PM, Alan M. Carroll
wrote:
> Leif,
>
>> Is the goal here to iterate over all headers? If so, maybe some sort of
>> iterator functionality would be more appropriate, similar to how we added
>> the iterator (with a callback) for lib records (i.e. TSRecordDump() )? Can
Leif,
> Is the goal here to iterate over all headers? If so, maybe some sort of
> iterator functionality would be more appropriate, similar to how we added the
> iterator (with a callback) for lib records (i.e. TSRecordDump() )? Can that
> help simplifying / improve such operations?
If you add
On Aug 15, 2014, at 11:23 AM, Alan M. Carroll
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 g
15 matches
Mail list logo
