trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shu Kit Chan <chanshu...@gmail.com>
Subject Re: Adding headers to 304 Responses
Date Sat, 23 Nov 2013 01:00:54 GMT
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 <chanshukit@gmail.com> 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 <moseleymark@gmail.com>wrote:
>
>> On Fri, Nov 22, 2013 at 11:25 AM, Shu Kit Chan <chanshukit@gmail.com>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.
>>
>
>

Mime
View raw message