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.html needs some polishing! Also, I lied about the headers.. but, really, this should be a feature. So long, i ----- Original Message ----- > 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
