Can ATS function as a SOCKs proxy?
-Juan
On Aug 14, 2014, at 5:22 PM, James Peach wrote:
> On Aug 12, 2014, at 12:34 PM, Juan Madrigal wrote:
>
>> Hi,
>>
>> I'm new to Apache Traffic Server (ATS) and wanted to know if ATS can handle
>> more then http/https proxying.
>>
>> Would I be able t
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
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 TSMimeH
10 matches
Mail list logo
