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 4842D100BF for ; Sat, 23 Nov 2013 01:01:20 +0000 (UTC) Received: (qmail 78776 invoked by uid 500); 23 Nov 2013 01:01:19 -0000 Delivered-To: apmail-trafficserver-users-archive@trafficserver.apache.org Received: (qmail 78713 invoked by uid 500); 23 Nov 2013 01:01:19 -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 78705 invoked by uid 99); 23 Nov 2013 01:01:19 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 23 Nov 2013 01:01:19 +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 chanshukit@gmail.com designates 74.125.82.52 as permitted sender) Received: from [74.125.82.52] (HELO mail-wg0-f52.google.com) (74.125.82.52) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 23 Nov 2013 01:01:15 +0000 Received: by mail-wg0-f52.google.com with SMTP id x13so1865239wgg.7 for ; Fri, 22 Nov 2013 17:00:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=MAg3w/BG3f27BN6x/Pt45t23HbXsIEs5o/SllKr4PNw=; b=Twm/m/Vx7yVsXq4UzD/Y73cOIXQ9Ppl3yhLt9hJTZzuO9lH6LndnbRapl5SvD15FBK 695ZLyWAh5xzSiQRFSkGeIs9b1XeLWNVAE7twgJkqTY2/r+aKZqhXbwguq8x5hITK1zk Mqx89PGzZhCtvez6bYbCFC7FC8IhTke/1bXc7NEj2btLGM6e794iSDS08M57tdSaH0CJ R2+fyqwP5M7dlk/BxlVdPs+nCbXpQo/G6WHF0A35jJaEdHVTf6dSMu3Tkl1LME3AaVBc uz3RlKRq9MQMrKCBdVTNqZNeh64vQtw2spTMxwDxdFWBHboeyoz3ePfvICPmAUqsiyhU Jsww== MIME-Version: 1.0 X-Received: by 10.194.78.77 with SMTP id z13mr5435021wjw.27.1385168454463; Fri, 22 Nov 2013 17:00:54 -0800 (PST) Received: by 10.216.144.73 with HTTP; Fri, 22 Nov 2013 17:00:54 -0800 (PST) In-Reply-To: References: Date: Fri, 22 Nov 2013 17:00:54 -0800 Message-ID: Subject: Re: Adding headers to 304 Responses From: Shu Kit Chan To: "users@trafficserver.apache.org" Content-Type: multipart/alternative; boundary=047d7bfcfc98aeb5bf04ebcda921 X-Virus-Checked: Checked by ClamAV on apache.org --047d7bfcfc98aeb5bf04ebcda921 Content-Type: text/plain; charset=ISO-8859-1 After re-reading your message, can you see if the results are any different if you use READ_RESPONSE_HDR_HOOK instead of SEND_RESPONSE_HDR_HOOK ? Thanks. Kit On Fri, Nov 22, 2013 at 4:46 PM, Shu Kit Chan wrote: > From the header_rewrite plugin perspective, > the 304 is coming straight out of ATS and not from origin server. That's > fine. > So all the plugin does is to look up "X-From-Apache" from this particular > HTTP response between ATS and the client. It can't find it. So it cancelled > the add-header operation for "X-ATS-1". > But the add-header operation for "X-ATS-2" is still getting done without > problem. > > Thanks. > > Kit > > > On Fri, Nov 22, 2013 at 4:20 PM, Mark Moseley wrote: > >> On Fri, Nov 22, 2013 at 11:25 AM, Shu Kit Chan wrote: >> >>> I think in your "conditional request" example, the response does not >>> have a X-From-Apache header. >>> The code is done in such a way that it will ignore add-header if the >>> value is empty. >>> >>> >>> >>>> If I send a non-conditional request (but without the Pragma: no-cache >>>> like in the first example), I get X-ATS-1 like in the Pragma: no-cache >>>> example. So 200 responses, whether cached or not cached, are getting the >>>> header copied over by headers_rewrite, just not in 304's. >>>> >>>> Is the not copying headers for a 304 expected behavior or should I open >>>> a ticket about it? >>>> >>> >>> >> Not sure what you mean. There's no corresponding origin request for the >> conditional request, since it was successfully cached. The 304 is coming >> straight out of ATS and not re-requesting from the origin server. So >> presumably ATS is filtering the list of headers it makes available for the >> headers_rewrite module. >> >> >> From what I can tell, the HttpTransact::build_response function in >> proxy/http/HttpTransact.cc seems to be doing that filtering. >> >> If doing this via headers_rewrite turns out not to be an option, it >> *seems* like I could add a corresponding MIME_FIELD_*, MIME_LEN_*, and >> MIME_PRESENCE_* entry to the arrays there (in 4.1.1, lines starting with >> 7697), as well as adding: >> >> * A new entry in proxy/hdrs/MIME.cc as well as the spots where things are >> assigned: MIME_LEN_* = hdrtoken_wks_to_length(MIME_FIELD_*); >> >> * A new entry to the fields array in lib/ts/mkdfa.c : {"MyHeader", >> "MIME_FIELD_...", 0}, >> >> * Find a new slot in the 'tokenized string mime presence masks' define's >> for MIME_PRESENCE_* in proxy/hdrs/HdrToken.h >> >> >> Though I'd obviously love to be able to do this without mucking with >> source code, since the likelihood of me causing random segfaults is high. >> > > --047d7bfcfc98aeb5bf04ebcda921 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
After re-reading your message, can you see if the res= ults are any different if you use READ_RESPONSE_HDR_HOOK instead of SEND_RE= SPONSE_HDR_HOOK ?

Thanks.

Kit


On Fri, Nov 22, 2013 at 4:46 PM, Shu Kit= Chan <chanshukit@gmail.com> wrote:
From the header_rewrite plugin perspective,=A0
the 304= is coming straight out of ATS and not from origin server. That's fine.=
So all the plugin does is to look up "X-From-Apache" f= rom this particular HTTP response between ATS and the client. It can't = find it. So it cancelled the add-header operation for "X-ATS-1".<= /div>
But the add-header operation for "X-ATS-2" is still getting = done without problem.

Thanks.

Kit
=


=
On Fri, Nov 22, 2013 at 4:20 PM, Mark Moseley <moseleymark@gmail.com> wrote:
Not sur= e what you mean. There's no corresponding origin request for the condit= ional request, since it was successfully cached. The 304 is coming straight= out of ATS and not re-requesting from the origin server. So presumably ATS= is filtering the list of headers it makes available for the headers_rewrit= e module.


From what I can tell, the HttpTran= sact::build_response function in proxy/http/HttpTransact.cc seems to be doi= ng that filtering.

If doing this v= ia headers_rewrite turns out not to be an option, it *seems* like I could a= dd a corresponding MIME_FIELD_*, MIME_LEN_*, and MIME_PRESENCE_* entry to t= he arrays there (in 4.1.1, lines starting with 7697), as well as adding:
* A new entry in proxy/hdrs/MIME.cc as= well as the spots where things are assigned: MIME_LEN_* =3D hdrtoken_wks_t= o_length(MIME_FIELD_*);

* A new entry to the fields array in lib/ts/= mkdfa.c : {"MyHeader", "MIME_FIELD_...", 0},

* Find a new slot in the 'tokenize= d string mime presence masks' define's for MIME_PRESENCE_* in proxy= /hdrs/HdrToken.h


Though I'd= obviously love to be able to do this without mucking with source code, sin= ce the likelihood of me causing random segfaults is high.


--047d7bfcfc98aeb5bf04ebcda921--