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 1973318994 for ; Fri, 9 Oct 2015 21:00:19 +0000 (UTC) Received: (qmail 63182 invoked by uid 500); 9 Oct 2015 21:00:18 -0000 Delivered-To: apmail-trafficserver-users-archive@trafficserver.apache.org Received: (qmail 63126 invoked by uid 500); 9 Oct 2015 21:00:18 -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 63116 invoked by uid 99); 9 Oct 2015 21:00:18 -0000 Received: from Unknown (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Oct 2015 21:00:18 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 107FA180A55 for ; Fri, 9 Oct 2015 21:00:18 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.901 X-Spam-Level: ** X-Spam-Status: No, score=2.901 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=3, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id Xw5Rk1nM3R67 for ; Fri, 9 Oct 2015 21:00:04 +0000 (UTC) Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id BBDBB20382 for ; Fri, 9 Oct 2015 21:00:03 +0000 (UTC) Received: by oiar126 with SMTP id r126so11111181oia.0 for ; Fri, 09 Oct 2015 13:59:56 -0700 (PDT) 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 :cc:content-type; bh=dscx3CvduCqGuFKVrTwz6QNObRkR/00QIaJkIHdw5K4=; b=TjAgiLK0PK2U1RoB3B2ifIQRU2qG5tN4YF2lz5PHMM2bZaPL1WQfTN7nv2p6633Ys2 hGMrBXpRblKTnfV/VzfqIgsUBLebRNmY0zmwNyhc0awiGcdTKYG57RoqkWHwYW7WQNeu hA6TXvx23Wf6GQooN9Qjb2aqrcIiJultr+H1BRP1jmPeol1zqtRj2aqb1iFXSt+JonFk fPgU7J8tTZOGmLmGTC6ecBSI8iHfLqQcaQD0URyXWyyLdyttdWQFfzkV5hXK7Af/cfAT 1hyXf+CJ8H2jwmwI0xeErXcL8CA+khEOSOh3iCk5tAfPsQ1Rix55vfhbcr0piqDOW/dV 7LEA== X-Received: by 10.202.212.73 with SMTP id l70mr8925536oig.54.1444424395902; Fri, 09 Oct 2015 13:59:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.48.99 with HTTP; Fri, 9 Oct 2015 13:59:36 -0700 (PDT) In-Reply-To: <1936746588.1615583.1444420741448.JavaMail.yahoo@mail.yahoo.com> References: <492764110.339257.1444239695173.JavaMail.yahoo@mail.yahoo.com> <953224170.527101.1444260461947.JavaMail.yahoo@mail.yahoo.com> <30778D2546DCBC44875BF75DC7C72778155B1FF2@MISOUT7MSGUSRCF.ITServices.sbc.com> <1889581984.1532341.1444411058768.JavaMail.yahoo@mail.yahoo.com> <1936746588.1615583.1444420741448.JavaMail.yahoo@mail.yahoo.com> From: Daniel Morilha Date: Fri, 9 Oct 2015 13:59:36 -0700 Message-ID: Subject: Re: header_rewrite to modify destination port based on request header To: "users@trafficserver.apache.org" , Alan Carroll Cc: Sudheer Vinukonda , Jeremy Payne , Scott Beardsley Content-Type: multipart/alternative; boundary=001a113d220205d65f0521b24312 --001a113d220205d65f0521b24312 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable let me work on this then, thanks guys! On Fri, Oct 9, 2015 at 12:59 PM, Alan Carroll wrote: > Yes, I don't see why this would be a problem. > > > > > On Friday, October 9, 2015 12:19 PM, Sudheer Vinukonda < > sudheerv@yahoo-inc.com> wrote: > > > Hi Daniel, > > +1 on the proposal.. > > AFAIK, header_rewrite is by no means deprecated or plan to be deprecated > (not in the near future, anyway) and it has a very wide set of production > users (including us). > > Please go ahead and submit a PR on github - unless there are strong > concerns, I can review/merge it. > > Thanks, > > Sudheer > > > > On Friday, October 9, 2015 9:55 AM, Daniel Morilha > wrote: > > > > Hi, after talking a quick look into header_rewrite source code, it looks > like it is just a matter of calling "expand" into the function which > validates and sets the port. If so, would the community be ok with such > addition? I really really would like to avoid the lua plugin only for thi= s. > Thanks. > On Oct 8, 2015 6:53 AM, "Brian Geffon" wrote: > > This will likely be discussed next month at the ATS summit in Sunnyvale, > CA (please sign up and join if you can make it, details on the wiki). > However, final discussions regarding things like this always take place o= n > the mailing list. > > > > > >Brian > > > >On Thursday, October 8, 2015, LIN, SHU-CHIH wrote: > > > >Hi: > >> > >>Any insight when Lua will be moved from "experimental" to =E2=80=9Cstab= le=E2=80=9D? Lua > looks to offer great flexibility (in consolidating existing plugins and t= o > add new custom changes) so wonder what may stop one from using it to hand= le > Production traffic? Understood one would need to assess the performance > overheads it may incur. > >> > >>Thanks, > >> > >>Shu-Chih > >> > >>From:Scott Beardsley [mailto:sbeards@yahoo-inc.com] > >>Sent: Wednesday, October 07, 2015 7:28 PM > >>To: Jeremy Payne ; users@trafficserver.apache.org > >>Subject: Re: header_rewrite to modify destination port based on request > header > >> > >>Thanks Jeremy, we we hoping to use an existing/stable plugin to do this > (lua appears to be "experimental" and we don't use it anywhere at the > moment). It seems like header_rewrite is 99% of the way there so if it > means adding this one feature we'd prefer that since it wouldn't involve > new config syntax and/or plugins. > >> > >>Scott > >> > >> > >>On Wednesday, October 7, 2015 1:41 PM, Jeremy Payne > wrote: > >> > >>Not sure if you are just researching or what.. But this same > functionality is also supported in the lua plugin. > >> > >> > http://trafficserver.readthedocs.org/en/6.0.x/reference/plugins/ts_lua.en= .html > >>ts.client_request.set_url_port > >> > >> > >>On Wed, Oct 7, 2015 at 12:41 PM, Scott Beardsley > wrote: > >>I'd like to modify the destination port based on an incoming request > header. It seems like everything I need is available in the header_rewrit= e > plugin except the value expansion in the "set-destination port" directive= . > In the docs it says that this expansion only works for add-header[1]. > >>> > >>>Is there a way to do something like the following via the existing > plugin, maybe my syntax is wrong? > >>> > >>>cond %{READ_REQUEST_HDR_HOOK} [AND] > >>>cond %{CLIENT-HEADER:NEW-PORT} /^[1-9][0-9]*$/ > >>>set-destination PORT %{CLIENT-HEADER:NEW-PORT} [L] > >>> > >>>When I test it I get this debug message: "Would set destination PORT t= o > an invalid range, skipping" > >>> > >>>Which points me at this code[2]. It looks like the _value variable is > set to the string "%{CLIENT-HEADER:NEW-PORT}" so I guess there is no > expansion... > >>> > >>>Assuming header_rewrite doesn't support this yet, are there any > objections to adding this feature? > >>> > >>>Thanks, > >>>Scott > >>>-- > >>>[1] > http://trafficserver.readthedocs.org/en/latest/reference/plugins/header_r= ewrite.en.html?highlight=3Dheader_rewrite#variable-expansion > >>>[2] > https://git-wip-us.apache.org/repos/asf?p=3Dtrafficserver.git;a=3Dblob;f= =3Dplugins/header_rewrite/operators.cc;h=3D5ce75f5985e3e42374814e5a46c361e4= 50bdd779;hb=3DHEAD#l228 > >> > >> > > > --=20 Daniel Morilha (dmorilha@gmail.com) --001a113d220205d65f0521b24312 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
let me work on this then, thanks guys!

On Fri, Oct 9,= 2015 at 12:59 PM, Alan Carroll <solidwallofcode@yahoo-inc.com= > wrote:
Yes, I don't see why this would be a problem.




On Friday, October 9, 2015 12:19 PM, Sudheer Vi= nukonda <sud= heerv@yahoo-inc.com> wrote:


Hi Dan= iel,

+1 on the proposal..

AFAIK, header_rewrite is by no means deprecated or= plan to be deprecated (not in the near future, anyway) and it has a very w= ide set of production users (including us).

Please go ahead and submit a PR on github - unless there are strong = concerns, I can review/merge it.

Thank= s,

Sudheer



On Friday, October 9, = 2015 9:55 AM, Daniel Morilha <dmorilha@gmail.com> wrote:



Hi, after ta= lking a quick look into header_rewrite source code, it looks like it is jus= t a matter of calling "expand" into the function which validates = and sets the port. If so, would the community be ok with such addition? I r= eally really would like to avoid the lua plugin only for this. Thanks.
On Oct 8, 2015 6:53 AM, "Brian Geffon" <briang@apach= e.org> wrote:

This will likely = be discussed next month at the ATS summit in Sunnyvale, CA (please sign up = and join if you can make it, details on the wiki). However, final discussio= ns regarding things like this always take place on the mailing list.
>
>
>Brian
>
>On Thursday, October 8, 2015, LIN, SH= U-CHIH <sl3241@att.com> wrote:
>
&= gt;Hi:
>>
>>Any insight wh= en Lua will be moved from "experimental" to =E2=80=9Cstable=E2=80= =9D? Lua looks to offer great flexibility (in consolidating existing plugin= s and to add new custom changes) so wonder what may stop one from using it = to handle Production traffic? Understood one would need to assess the perfo= rmance overheads it may incur.
>>
>>Thanks,
>>
>>Shu= -Chih
>>
>>From:Scott Bear= dsley [mailto:sbeards@yahoo-inc.com]
>>Sent: We= dnesday, October 07, 2015 7:28 PM
>>To: Jeremy Payn= e <jp557198@gmail.com>; users@trafficserver.apache.org>>Subject: Re: header_rewrite to modify destination p= ort based on request header
>>
&= gt;>Thanks Jeremy, we we hoping to use an existing/stable plugin to do t= his (lua appears to be "experimental" and we don't use it any= where at the moment). It seems like header_rewrite is 99% of the way there = so if it means adding this one feature we'd prefer that since it wouldn= 't involve new config syntax and/or plugins.
>>= ;
>>Scott
>>
>>
>>On Wednesday, October 7, 2015 1:4= 1 PM, Jeremy Payne <jp557198@gmail.com> wrote:
>= >
>>Not sure if you are just researching or wha= t.. But this same functionality is also supported in the lua plugin.
>>
>>http://trafficserver.readthedocs.org/en/6.0.x/referenc= e/plugins/ts_lua.en.html
>>ts.client_request.se= t_url_port
>>
>>
>>On Wed, Oct 7, 2015 at 12:41 PM, Scott Beardsley <sbear= ds@yahoo-inc.com> wrote:
>>I'd like to m= odify the destination port based on an incoming request header. It seems li= ke everything I need is available in the header_rewrite plugin except the v= alue expansion in the "set-destination port" directive. In the do= cs it says that this expansion only works for add-header[1].
>>>
>>>Is there a way to do somet= hing like the following via the existing plugin, maybe my syntax is wrong? =
>>>
>>>cond %{READ_= REQUEST_HDR_HOOK} [AND]
>>>cond %{CLIENT-HEADER:= NEW-PORT} /^[1-9][0-9]*$/
>>>set-destination POR= T %{CLIENT-HEADER:NEW-PORT} [L]
>>>
>>>When I test it I get this debug message: "Would set= destination PORT to an invalid range, skipping"
>= ;>>
>>>Which points me at this code[2]. I= t looks like the _value variable is set to the string "%{CLIENT-HEADER= :NEW-PORT}" so I guess there is no expansion...
>= >>
>>>Assuming header_rewrite doesn't= support this yet, are there any objections to adding this feature?
>>>
>>>Thanks,
>>>Scott
>>>--
= >>>[1] http://trafficserver.readthedo= cs.org/en/latest/reference/plugins/header_rewrite.en.html?highlight=3Dheade= r_rewrite#variable-expansion
>>>[2] https://git-wip-u= s.apache.org/repos/asf?p=3Dtrafficserver.git;a=3Dblob;f=3Dplugins/header_re= write/operators.cc;h=3D5ce75f5985e3e42374814e5a46c361e450bdd779;hb=3DHEAD#l= 228
>>
>>



--
Da= niel Morilha (dmori= lha@gmail.com)
--001a113d220205d65f0521b24312--