Return-Path: X-Original-To: apmail-trafficserver-users-archive@www.apache.org Delivered-To: apmail-trafficserver-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 92B9F100C8 for ; Mon, 25 Nov 2013 19:21:42 +0000 (UTC) Received: (qmail 97680 invoked by uid 500); 25 Nov 2013 19:21:42 -0000 Delivered-To: apmail-trafficserver-users-archive@trafficserver.apache.org Received: (qmail 97579 invoked by uid 500); 25 Nov 2013 19:21:42 -0000 Mailing-List: contact users-help@trafficserver.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@trafficserver.apache.org Delivered-To: mailing list users@trafficserver.apache.org Received: (qmail 97571 invoked by uid 99); 25 Nov 2013 19:21:42 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Nov 2013 19:21:42 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of dmorilha@gmail.com designates 209.85.214.49 as permitted sender) Received: from [209.85.214.49] (HELO mail-bk0-f49.google.com) (209.85.214.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Nov 2013 19:21:37 +0000 Received: by mail-bk0-f49.google.com with SMTP id my13so2150081bkb.36 for ; Mon, 25 Nov 2013 11:21:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=HdfdYYstJ2jeNVFmcbOONtdjXG9vYgJ+rlcQ9r8ut04=; b=Qg0Z5F2nWy52c1nMfIWFoQer9u8aGJGyz9gRJLIpbCt0gXRjyXZbGCRamt8Y0cD+QV p/2kEUjf0BX611BjSdm0jHVzFK/ORgSGS2ckpd37t5T+cAKz2mzeMP0Xu+m7OuvyZ7HP GOxgEPKcXDQR4eb1YdDPK7enS3QQhALUo3tMuIKYaqMPUoKV33i3lOb5h7B8MH0jhhOf iXmKkr+vweWAkHF6EijFdNyBdYAYHjwhzNYIRE52ogdg89Br6fiP8W8xGVMNpUqyf1W0 p323IcfZL9+dZ/G7cjVCAEyHoBEF8UfqrbyCUYsNJ7xxXbfv+kjxtAnu4tnE8m/aoqpH sQqQ== X-Received: by 10.205.74.69 with SMTP id yv5mr2893703bkb.35.1385407275831; Mon, 25 Nov 2013 11:21:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.167.14 with HTTP; Mon, 25 Nov 2013 11:20:55 -0800 (PST) In-Reply-To: References: From: Daniel Morilha Date: Mon, 25 Nov 2013 11:20:55 -0800 Message-ID: Subject: Re: gzip To: users@trafficserver.apache.org Content-Type: multipart/alternative; boundary=f46d0415595a8bbb4904ec05444f X-Virus-Checked: Checked by ClamAV on apache.org --f46d0415595a8bbb4904ec05444f Content-Type: text/plain; charset=UTF-8 also AFAICT gzip plug-in has no inflate code. On Mon, Nov 25, 2013 at 11:19 AM, Daniel Morilha 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 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 >> >>> 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) --f46d0415595a8bbb4904ec05444f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 transformati= on 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 i= nternal APIs myself based on those conditions but that would mean I would c= reate the gzip headers myself and also make sure the plug-in gets loaded co= rrectly, which sounds hackish.

Thanks,


On Mon, Nov 25, 2013 at 11:12 AM, Otto van d= er 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 d= eflating the content after the transformation kicks in.
I believe that's a common problem that most of the tra= nsformation 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 integ= rate 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 (dmo= rilha@gmail.com)




<= /div>--
Daniel Morilha (= dmorilha@gmail.com<= /a>)


--
Daniel Moril= ha (dmorilha@gmail.com) --f46d0415595a8bbb4904ec05444f--