> Also, I lied about the headers.. but, really, this should be a feature.
That was what I was hinting at as well, and I think it should work in its current form. Other plugins should be able to control compression through the accept encoding header > See, ugh.. Otto, this > https://trafficserver.readthedocs.org/en/latest/>reference/plugins/gzip.en.html needs some polishing! I see :-) I'll fix that. 2013/11/25 Igor Galić <[email protected]> > I think what you're looking for is to trigger the gzip plugin through > headers. > Currently that happens automatically if you just enable it, and there are > Accept-Encoding: gzip headers. > > Your transformation chain could set a trigger, that the gzip plugin could > react to. > > See, ugh.. Otto, this > https://trafficserver.readthedocs.org/en/latest/reference/plugins/gzip.en.htmlneeds > some polishing! > > Also, I lied about the headers.. but, really, this should be a feature. > > So long, > > i > > ------------------------------ > > so then might question would be is it possible to generate the gzip plugin > configuration into another transformation plug-in or this is only based on > the configuration file provided on plugins.conf ? > > thanks, > > > On Mon, Nov 25, 2013 at 11:25 AM, Otto van der Schaaf > <[email protected]>wrote: > >> The gzip plugin will run when configured to do so, plus when the >> accept-encoding request header meets the criteria (e.g. 'gzip' is specified) >> >> Regrettably, it doesn't support inflation at this moment. >> I think that should go into a separate plugin, so that can be configured >> into its own place into the plugin chain (probably before any >> transformations). >> >> Otto >> >> >> 2013/11/25 Daniel Morilha <[email protected]> >> >>> 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]) >>> >> >> > > > -- > Daniel Morilha ([email protected]) > > > > > -- > Igor Galić > > Tel: +43 (0) 664 886 22 883 > Mail: [email protected] > URL: http://brainsware.org/ > GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641 > >
