trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Morilha <dmori...@gmail.com>
Subject Re: gzip
Date Mon, 25 Nov 2013 19:20:55 GMT
also AFAICT gzip plug-in has no inflate code.


On Mon, Nov 25, 2013 at 11:19 AM, Daniel Morilha <dmorilha@gmail.com> wrote:

> the transformation runs for some of the requests and I didn't see how to
> tell the gzip to run or not... I don't want to unecessarily
> inflate/deflate. Does it make sense?
>
> I was inclined into call the gzip plug-in internal APIs myself based on
> those conditions but that would mean I would create the gzip headers myself
> and also make sure the plug-in gets loaded correctly, which sounds hackish.
>
> Thanks,
>
>
> On Mon, Nov 25, 2013 at 11:12 AM, Otto van der Schaaf <oschaaf@gmail.com>wrote:
>
>> Wouldn't it be a solution to configure the gzip plugin to run after your
>> own transformation?
>>
>> Otto van der Schaaf
>>
>>
>> 2013/11/25 Daniel Morilha <dmorilha@gmail.com>
>>
>>> Hi,
>>>
>>> I am writing a transformation plug-in and I bumped up into the problem
>>> of deflating the content after the transformation kicks in.
>>>
>>> I believe that's a common problem that most of the transformation
>>> plug-ins may suffer with.
>>>
>>> I am aware ESI implements gzip itself and after giving a quick look into
>>> the GZIP plug-in and realizing it will be tough to integrate into another
>>> transformation plug-in I am inclined to do the same.
>>>
>>> Couldn't we have the gzip capabilities baked into the C API. The
>>> Linked'in atscppapi provides a nice way where you can inflate before the
>>> transformers and defalte after all of them had passed. Only problem is the
>>> dependency it creates on their APIs.
>>>
>>> thanks,
>>> --
>>> Daniel Morilha (dmorilha@gmail.com)
>>>
>>
>>
>
>
> --
> Daniel Morilha (dmorilha@gmail.com)
>



-- 
Daniel Morilha (dmorilha@gmail.com)

Mime
View raw message