also AFAICT gzip plug-in has no inflate code.
On Mon, Nov 25, 2013 at 11:19 AM, Daniel Morilha <[email protected]> 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 > <[email protected]>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 <[email protected]> >> >>> 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 ([email protected]) >>> >> >> > > > -- > Daniel Morilha ([email protected]) > -- Daniel Morilha ([email protected])
