On Mon, Mar 25, 2013 at 11:58 PM, Roy T. Fielding field...@gbiv.com wrote:
On Mar 13, 2013, at 10:20 AM, Graham Leggett wrote:
I don't read it that way from the spec, I think it all comes down to the
phrase without successful revalidation with the origin server. I read it
as without
I have already created the bugzilla issue #54706 nearly 2 weeks ago,
about mod_cache that may serve cached private= or no-cache= response
headers.
Should I link something discussion from here or the patch to this issue ?
Regards,
Yann.
On 27 Mar 2013, at 6:06 PM, Yann Ylavic ylavic@gmail.com wrote:
Index: modules/cache/mod_cache.h
===
--- modules/cache/mod_cache.h (revision 1461557)
+++ modules/cache/mod_cache.h (working copy)
@@ -152,9 +152,12 @@
/*
On Wed, Mar 27, 2013 at 5:44 PM, Graham Leggett minf...@sharp.fm wrote:
Been snowed under and haven't had a chance to look at this in detail, but one
quick thing - we would definitely want to be able to backport this to v2.4 so
as to get it into people's hands, and to do that, we cannot
In fact this patch is probably better since it does not change
h-resp_hdrs before calling cache_accept_headers() which uses them.
Regars,
Yann.
Index: modules/cache/cache_util.c
===
--- modules/cache/cache_util.c (revision 1461557)
Sorry for my precipitation, the Content-Type is stripped from the
validated (stale) headers with the previous patch, we have to do a
copy like below.
Regards,
Yann.
Index: modules/cache/cache_util.c
===
---
The latest patch is attached to bugzilla #54706.
Regards,
Yann.
On Mar 13, 2013, at 10:20 AM, Graham Leggett wrote:
On 11 Mar 2013, at 12:50 PM, Yann Ylavic ylavic@gmail.com wrote:
The way I read the spec, the specified field-name(s) MUST NOT be sent in
the response to a subsequent request without successful revalidation with
the origin server.
Here is the patch that strips the no-cache= or private= specified
headers after the origin server's validation, leaving the only headers
updated by the origin.
Regards,
Yann.
Index: modules/cache/cache_storage.c
===
---
On 11 Mar 2013, at 12:50 PM, Yann Ylavic ylavic@gmail.com wrote:
The way I read the spec, the specified field-name(s) MUST NOT be sent in
the response to a subsequent request without successful revalidation with
the origin server. What this means is that if the specified field names are
On Wed, Mar 13, 2013 at 6:20 PM, Graham Leggett minf...@sharp.fm wrote:
On 11 Mar 2013, at 12:50 PM, Yann Ylavic ylavic@gmail.com wrote:
The way I read the spec, the specified field-name(s) MUST NOT be sent in
the response to a subsequent request without successful revalidation with
the
On 13 Mar 2013, at 7:27 PM, Yann Ylavic ylavic@gmail.com wrote:
How would the origin invalidate a Set-Cookie, with an empty one ?
I would imagine with a 200 OK.
Roy would be able to confirm.
Regards,
Graham
--
smime.p7s
Description: S/MIME cryptographic signature
On Wed, Mar 13, 2013 at 5:27 PM, Yann Ylavic ylavic@gmail.com wrote:
How would the origin invalidate a Set-Cookie, with an empty one ?
Regards,
Yann.
Set it again, with an in the past expiry date.
Cheers
Tom
On Wed, Mar 13, 2013 at 6:30 PM, Graham Leggett minf...@sharp.fm wrote:
On 13 Mar 2013, at 7:27 PM, Yann Ylavic ylavic@gmail.com wrote:
How would the origin invalidate a Set-Cookie, with an empty one ?
I would imagine with a 200 OK.
Roy would be able to confirm.
Well, I can't see the
On Wed, Mar 13, 2013 at 6:35 PM, Tom Evans tevans...@googlemail.com wrote:
On Wed, Mar 13, 2013 at 5:27 PM, Yann Ylavic ylavic@gmail.com wrote:
How would the origin invalidate a Set-Cookie, with an empty one ?
Regards,
Yann.
Set it again, with an in the past expiry date.
Well, that's
On 13 Mar 2013, at 17:41, Yann Ylavic ylavic@gmail.com wrote:
On Wed, Mar 13, 2013 at 6:35 PM, Tom Evans tevans...@googlemail.com wrote:
On Wed, Mar 13, 2013 at 5:27 PM, Yann Ylavic ylavic@gmail.com wrote:
How would the origin invalidate a Set-Cookie, with an empty one ?
Regards,
On Wed, Mar 13, 2013 at 9:28 PM, Tim Bannister is...@jellybaby.net wrote:
Is this the situation you're worried about:
ClientA: GET /foo HTTP/1.1
ReverseProxy: GET /foo HTTP/1.1
Origin: HTTP/1.1 200 OK
Origin: Set-Cookie: data=AA
Origin: Cache-Control: private=Set-Cookie
ReverseProxy:
On Sun, Mar 10, 2013 at 1:55 AM, Graham Leggett minf...@sharp.fm wrote:
On 04 Mar 2013, at 8:22 PM, ylavic dev ylavic@gmail.com wrote:
For what I understand, mod_cache is allowed to serve its cached entity
(though without the specified header(s)).
I read this through again, this time
On 04 Mar 2013, at 8:22 PM, ylavic dev ylavic@gmail.com wrote:
I've been working on a patch for mod_cache to deal (fully) with the response
header Cache-Control and the no-cache=header or private=header directives.
This feature is mainly used with the Set-Cookie header, and allows the
Hi,
On Mon, Mar 4, 2013 at 7:22 PM, ylavic dev ylavic@gmail.com wrote:
I've been working on a patch for mod_cache to deal (fully) with the
response header Cache-Control and the no-cache=header or private=header
directives.
I realize that, maybe, the patch should have been included in the
On 06 Mar 2013, at 12:04 PM, Yann Ylavic ylavic@gmail.com wrote:
I've been working on a patch for mod_cache to deal (fully) with the
response header Cache-Control and the no-cache=header or private=header
directives.
I realize that, maybe, the patch should have been included in the
Hi,
I've been working on a patch for mod_cache to deal (fully) with the
response header Cache-Control and the no-cache=header or private=header
directives.
This feature is mainly used with the Set-Cookie header, and allows the
origin server to control the caching of that particular header.
22 matches
Mail list logo
