Re: [PATCH] Cache-Control overwriting hack
hnordstrom has voted tweak. Status is now: Semi-approved Comment: Better to turn it the other way around. Add a new header to be used as substitute for Cache-Control by the reverse proxy. For details, see: http://bundlebuggy.aaronbentley.com/project/squid/request/%3CE8FE3C35-0CBA-4272-9194-DEF885267638%40semihuman.com%3E Project: Squid
Re: [PATCH] Cache-Control overwriting hack
Henrik Nordstrom wrote: hnordstrom has voted tweak. Status is now: Semi-approved Comment: Better to turn it the other way around. Add a new header to be used as substitute for Cache-Control by the reverse proxy. For details, see: http://bundlebuggy.aaronbentley.com/project/squid/request/%3CE8FE3C35-0CBA-4272-9194-DEF885267638%40semihuman.com%3E Project: Squid That would be the ESI Surrogate-Control: header Robert brought up. As indicated to earlier. Implementing Surrogate-Control: for reverse-proxy mode would be acceptable. Adding new headers to do the same purpose in worse ways is not. Amos -- Please be using Current Stable Squid 2.7.STABLE6 or 3.0.STABLE18 Current Beta Squid 3.1.0.13
Re: [PATCH] Cache-Control overwriting hack
I'm neutral on this. Chris, the what that Robert talks about is what I had originally thought, but I'm not dead-set either way... On 05/05/2009, at 12:25 PM, Robert Collins wrote: On Tue, 2009-05-05 at 12:17 +1000, Mark Nottingham wrote: The functionality? Very much so; I've been thinking about adding this sort of thing for a while. Very useful if you're running an accelerator. No, a rewrite of the approach - seems to me that a functional version many things support a new version that few things support. That said, I did have one concern - I think its clearer to say: 'surrogates use this header, clients get the original cache-control', than to say: 'surrogates use cache-control, and if there is a header X they replace cache-control with X'. The latter will be harder to debug by network traces I think. -Rob -- Mark Nottingham m...@yahoo-inc.com
[PATCH] Cache-Control overwriting hack
Hi, This is a patch of probably limited utility, but I'll send it out anyway and leave it for you folks to decide :) It was written against 2.7STABLE6 but patches cleanly into HEAD. The purpose of this patch is to support the use of an alternate Cache-Control header in reverse-proxy environments. The patch consists of a new config directive, replace_client_cc, and code in client_side.c that is called if that config option is enabled. The new code then looks for the existence of a header titled Client- Cache-Control which should contain syntax similar to that of a normal Cache-Control header. When present, Squid will delete the existing Cache-Control header if it exists, replace it with the contents of Client-Cache-Control, then delete the Client-Cache-Control header. So, the end result is that you have one Cache-Control header that squid pays attention to, and then a completely different one that client browsers will see. A couple TODOs on this if folks agree it's worthwhile: 1. Change the config option to a named header, eliminating the need to hard-code Client-Cache-Control (at the cost of using httpHeaderFindByName() instead of httpHeaderGetList() which seems much more costly CPU-wise). 2. Allow for some method by which the original Cache-Control header can be preserved for diag purposes (maybe add in as X-Original-Cache- Control?) Feedback appreciated, etc... -C squid-2.7.STABLE6-client-cc-patch.diff Description: Binary data
Re: [PATCH] Cache-Control overwriting hack
Bundle Buggy has detected this merge request. For details, see: http://bundlebuggy.aaronbentley.com/project/squid/request/%3CE8FE3C35-0CBA-4272-9194-DEF885267638%40semihuman.com%3E Project: Squid
Re: [PATCH] Cache-Control overwriting hack
Hi, This is a patch of probably limited utility, but I'll send it out anyway and leave it for you folks to decide :) It was written against 2.7STABLE6 but patches cleanly into HEAD. The purpose of this patch is to support the use of an alternate Cache-Control header in reverse-proxy environments. The patch consists of a new config directive, replace_client_cc, and code in client_side.c that is called if that config option is enabled. The new code then looks for the existence of a header titled Client- Cache-Control which should contain syntax similar to that of a normal Cache-Control header. When present, Squid will delete the existing Cache-Control header if it exists, replace it with the contents of Client-Cache-Control, then delete the Client-Cache-Control header. So, the end result is that you have one Cache-Control header that squid pays attention to, and then a completely different one that client browsers will see. A couple TODOs on this if folks agree it's worthwhile: 1. Change the config option to a named header, eliminating the need to hard-code Client-Cache-Control (at the cost of using httpHeaderFindByName() instead of httpHeaderGetList() which seems much more costly CPU-wise). 2. Allow for some method by which the original Cache-Control header can be preserved for diag purposes (maybe add in as X-Original-Cache- Control?) Feedback appreciated, etc... -C Oh dear. Why are you thinking this is necessary? AFAIK, header_access and header_replace even in Squid-2 are supposed to do exactly that. If not that is a bug which needs to be fixed. Amos
Re: [PATCH] Cache-Control overwriting hack
surrogate-control is an existing, defined header that should do this cleanly, and squid-3 already supports. -Rob signature.asc Description: This is a digitally signed message part
Re: [PATCH] Cache-Control overwriting hack
My reading of header_replace only allows replacing header text with a fixed string, not any sort of dynamic text. The use case is where one wants this particular Squid instance to use a set of Cache-Control headers that are explicitly hidden from downstream caches as well as downstream clients. -C On May 4, 2009, at 7:28 PM, Amos Jeffries wrote: Hi, This is a patch of probably limited utility, but I'll send it out anyway and leave it for you folks to decide :) It was written against 2.7STABLE6 but patches cleanly into HEAD. The purpose of this patch is to support the use of an alternate Cache-Control header in reverse-proxy environments. The patch consists of a new config directive, replace_client_cc, and code in client_side.c that is called if that config option is enabled. The new code then looks for the existence of a header titled Client- Cache-Control which should contain syntax similar to that of a normal Cache-Control header. When present, Squid will delete the existing Cache-Control header if it exists, replace it with the contents of Client-Cache-Control, then delete the Client-Cache-Control header. So, the end result is that you have one Cache-Control header that squid pays attention to, and then a completely different one that client browsers will see. A couple TODOs on this if folks agree it's worthwhile: 1. Change the config option to a named header, eliminating the need to hard-code Client-Cache-Control (at the cost of using httpHeaderFindByName() instead of httpHeaderGetList() which seems much more costly CPU-wise). 2. Allow for some method by which the original Cache-Control header can be preserved for diag purposes (maybe add in as X-Original-Cache- Control?) Feedback appreciated, etc... -C Oh dear. Why are you thinking this is necessary? AFAIK, header_access and header_replace even in Squid-2 are supposed to do exactly that. If not that is a bug which needs to be fixed. Amos
Re: [PATCH] Cache-Control overwriting hack
Yeah, but if I had a do-over, I'd make it simpler. This is *much* simpler... On 05/05/2009, at 9:46 AM, Robert Collins wrote: surrogate-control is an existing, defined header that should do this cleanly, and squid-3 already supports. -Rob -- Mark Nottingham m...@yahoo-inc.com
Re: [PATCH] Cache-Control overwriting hack
On Tue, 2009-05-05 at 11:57 +1000, Mark Nottingham wrote: Yeah, but if I had a do-over, I'd make it simpler. This is *much* simpler... I think you are entitled to that... but is it needed? -Rob signature.asc Description: This is a digitally signed message part
Re: [PATCH] Cache-Control overwriting hack
The functionality? Very much so; I've been thinking about adding this sort of thing for a while. Very useful if you're running an accelerator. On 05/05/2009, at 12:12 PM, Robert Collins wrote: On Tue, 2009-05-05 at 11:57 +1000, Mark Nottingham wrote: Yeah, but if I had a do-over, I'd make it simpler. This is *much* simpler... I think you are entitled to that... but is it needed? -Rob -- Mark Nottingham m...@yahoo-inc.com
Re: [PATCH] Cache-Control overwriting hack
On Tue, 2009-05-05 at 12:17 +1000, Mark Nottingham wrote: The functionality? Very much so; I've been thinking about adding this sort of thing for a while. Very useful if you're running an accelerator. No, a rewrite of the approach - seems to me that a functional version many things support a new version that few things support. That said, I did have one concern - I think its clearer to say: 'surrogates use this header, clients get the original cache-control', than to say: 'surrogates use cache-control, and if there is a header X they replace cache-control with X'. The latter will be harder to debug by network traces I think. -Rob signature.asc Description: This is a digitally signed message part
