Henrik Nordstrom wrote:
But the unique identity of the response entity is defined by request-URI
+ ETag and/or Content-Location. The cache is not supposed to evaluate
Accept-* headers in determining the entity identity, only the origin
server.
However, on an initial request (ie,
ons 2006-12-13 klockan 08:51 -0500 skrev Brian Akins:
However, on an initial request (ie, non-conditional) we do not have an etag
from
the client, we only have info like Host, URI, Accept-*, etc. So, how would
the
cache identify which entity to serve in this case?
You have the URL and
Henrik Nordstrom wrote:
mån 2006-12-11 klockan 14:25 -0500 skrev Brian Akins:
So, multiple variants of the same object can have the same Etag, but still be
different cached objects.
Your implementation ignores RFC 2616 13.6 Caching Negotiated Responses,
but is otherwise fine. It's
tis 2006-12-12 klockan 09:20 -0500 skrev Brian Akins:
Only conditional requests from clients, generally, have If-None-Match
headers.
Correct. It's a conditional. These days you also see them from Squid
btw.
So the only way for a cache, on an initial request from a client, to
determine
This is not a response to any post on this subject, but more of a comment. Here
is a real world example of how we use deflate and etags with our cache. (Note
this is very similar to mod_cache, but I do not know the inner workings of it as
well).
1. Generate key from URI and ap_get_servername
Let me preface all comments by saying that I AGREE with BOTH
Roy and Henrik... If Apache is sending the same exact (strong)
ETag value for both a compressed and an identity variant of
the same entity... then, according to current RFC content,
that is broken behavior and it should be fixed.
You
On 12/09/2006 06:52 AM, Roy T. Fielding wrote:
The best solution is to not mess with content-encoding at all, which
gets us out of both this consistency problem and related problems
with the entity-header fields (content-md5, signatures, etc.).
That is why transfer encoding was invented
On 12/9/06, Ruediger Pluem [EMAIL PROTECTED] wrote:
The existing filter needs to modify the ETag field value (and
any other entity-dependent values that we can think of) or be
removed as a feature. Weak etags are not a solution -- being able
to make range requests of large cached
On 12/9/06, Roy T. Fielding [EMAIL PROTECTED] wrote:
The best solution is to not mess with content-encoding at all, which
gets us out of both this consistency problem and related problems
with the entity-header fields (content-md5, signatures, etc.).
That is why transfer encoding was invented in
On 12/09/2006 03:23 PM, Justin Erenkrantz wrote:
On 12/9/06, Ruediger Pluem [EMAIL PROTECTED] wrote:
Would the following patch address all your points for a CE mod_deflate
filter?
No - this patch breaks conditional GETs which is what I'm against.
Ok, to be honest my question was more
On 12/9/06, Ruediger Pluem [EMAIL PROTECTED] wrote:
Thanks for giving the pointer to ap_meets_conditions. So content compressed
by mod_deflate would not stand conditional requests based on ETags any longer.
That would be bad. Would it help if we simply unset the ETag in mod_deflate?
mod_filter
On 12/09/2006 07:02 PM, Justin Erenkrantz wrote:
On 12/9/06, Ruediger Pluem [EMAIL PROTECTED] wrote:
Thanks for giving the pointer to ap_meets_conditions. So content
compressed
by mod_deflate would not stand conditional requests based on ETags any
longer.
That would be bad. Would it help
fre 2006-12-08 klockan 15:35 -0800 skrev Justin Erenkrantz:
As Kevin mentioned, Squid is only using the ETag and is ignoring the
Vary header. That's the crux of the broken behavior on their part.
If they want to point out minor RFC violations in Apache, then we can
play that game as well.
lör 2006-12-09 klockan 15:23 +0100 skrev Justin Erenkrantz:
See the problem here is that you have to teach ap_meets_conditions()
about this. An ETag of 1234-gzip needs to also satisfy a
conditional request when the ETag when ap_meets_conditions() is run is
1234. In other words,
lör 2006-12-09 klockan 19:02 +0100 skrev Justin Erenkrantz:
AIUI, many caches do not allow the response to be cached at all if it
doesn't have an ETag.
Most still caches it, but for example Mozilla has bugs vrt Vary handling
if there is no ETag and the conditions changes..
In the ideal
fre 2006-12-08 klockan 15:40 -0800 skrev Justin Erenkrantz:
I think we all (hopefully) agree that a weak ETag is ideally what
mod_deflate should add.
Please read RFC2616 13.6 Caching Negotiated Responses for an in-depth
description of how caches should handle Vary. And please stop lying
about
lör 2006-12-09 klockan 05:44 -0500 skrev [EMAIL PROTECTED]:
It's relevant to the extent that I think there are still some things
missing from the RFCs with regards to all this which is why a piece
of software like SQUID might be doing the wrong thing as well.
Ater reading the RFC on this
Justin wrote...
No - this patch breaks conditional GETs which is what I'm against.
See the problem here is that you have to teach ap_meets_conditions()
about this. An ETag of 1234-gzip needs to also satisfy a
conditional request when the ETag when ap_meets_conditions() is run is
1234.
And please stop lying about Squid.
C'mon Henrik. No one is intentionally trying to LIE about Squid.
If you are referring to Justin quoting ME let me supply a big
fat MEA CULPA here and say right now that I haven't looked
at the SQUID Vary/ETag code since the last major release
and I DO NOT KNOW
lör 2006-12-09 klockan 20:38 -0500 skrev [EMAIL PROTECTED]:
If you are referring to Justin quoting ME let me supply a big
fat MEA CULPA here and say right now that I haven't looked
at the SQUID Vary/ETag code since the last major release
and I DO NOT KNOW FOR SURE what SQUID is doing ( or
On 12/8/06, Henrik Nordstrom [EMAIL PROTECTED] wrote:
No, that won't work. You still be just as non-conforming by doing that.
But if mod_deflate may to produce different octet-level results on
different requests for the same original entity then it must do this in
addition to other transforms of
On 12/8/06, Henrik Nordstrom [EMAIL PROTECTED] wrote:
The protocol is quite fine as it is, and not easy to change. As it is
now it's mainly a matter of understanding that mod_deflate does create a
completely new entity from the original one. To the protocol it's
exactly the same as when using
fre 2006-12-08 klockan 14:47 +0100 skrev Justin Erenkrantz:
mod_deflate is certainly not creating a new resource
It is creating a new HTTP entity. Not a new object on your server, but
still a new unique HTTP entity with different characteristics from the
identity encoding.
If we were talking
fre 2006-12-08 klockan 14:40 +0100 skrev Justin Erenkrantz:
Uh, no, they *are* semantically equivalent - but, yes, not
syntactically (bit-for-bit) equivalent. You inflate the response and
you get exactly what the ETag originally represented.
To entities is only semantically equivalent if
tor 2006-12-07 klockan 02:42 +0100 skrev Justin Erenkrantz:
-1 on adding semantic junk to the existing ETag (and keeping it
strong); that's blatantly uncool. Any generated ETag from mod_deflate
should either be the original strong version or a weak version of any
previous etag. mod_deflate
fre 2006-12-08 klockan 14:40 +0100 skrev Justin Erenkrantz:
Uh, no, they *are* semantically equivalent - but, yes, not
syntactically (bit-for-bit) equivalent. You inflate the response and
you get exactly what the ETag originally represented.
To entities is only semantically equivalent if
Argh, my stupid ISP is losing apache email again because they use
spamcop.
On Dec 7, 2006, at 2:45 PM, Henrik Nordstrom wrote:
tor 2006-12-07 klockan 02:42 +0100 skrev Justin Erenkrantz:
-1 on adding semantic junk to the existing ETag (and keeping it
strong); that's blatantly uncool. Any
In other words, Henrik has it right. It is our responsibility to
assign different etags to different variants because doing otherwise
may result in errors on shared caches that use the etag as a variant
identifier.
Henrik is trying to make it sound like it is all Apache's fault.
It is not.
fre 2006-12-08 klockan 15:03 -0500 skrev [EMAIL PROTECTED]:
To ONLY ever use ETag as a the end-all-be-all for variant
identification is, itself, a mistake.
Well, this area of the HTTP specs is pretty clear in my eyes, but then
I have read it up and down too many times unwinding the tangled
fre 2006-12-08 klockan 11:44 -0800 skrev Roy T. Fielding:
In other words, Henrik has it right. It is our responsibility to
assign different etags to different variants because doing otherwise
may result in errors on shared caches that use the etag as a variant
identifier.
Thanks ;-)
fre 2006-12-08 klockan 22:28 +0100 skrev Henrik Nordstrom:
A strong ETag must be unique among all variants of a given URI, that is
all different forms of entities that may reside under the URI and all
their past and future versions.
Forgot the last piece there which clears many doubts:
On 12/8/06, Roy T. Fielding [EMAIL PROTECTED] wrote:
What we should be doing is sending transfer-encoding, not content-
encoding,
and get past the chicken and egg dilemma of that feature in HTTP.
If we are changing content-encoding, then we must behave as if there
are two different files on the
On 12/8/06, Henrik Nordstrom [EMAIL PROTECTED] wrote:
A strong ETag must be unique among all variants of a given URI, that is
all different forms of entities that may reside under the URI and all
their past and future versions.
A weak ETag may be shared by two variants/versions if and only if
On Dec 8, 2006, at 3:35 PM, Justin Erenkrantz wrote:
On 12/8/06, Roy T. Fielding [EMAIL PROTECTED] wrote:
What we should be doing is sending transfer-encoding, not content-
encoding,
and get past the chicken and egg dilemma of that feature in HTTP.
If we are changing content-encoding, then we
tor 2006-12-07 klockan 02:31 +0100 skrev Justin Erenkrantz:
mod_deflate should just add the W/ prefix if it's not already there. --
justin
No, that won't work. You still be just as non-conforming by doing that.
But if mod_deflate may to produce different octet-level results on
different
tor 2006-12-07 klockan 02:42 +0100 skrev Justin Erenkrantz:
-1 on adding semantic junk to the existing ETag (and keeping it
strong); that's blatantly uncool. Any generated ETag from mod_deflate
should either be the original strong version or a weak version of any
previous etag. mod_deflate
Roy T. Fielding wrote:
Protocol issues really should be brought up on the dev list, with an
appropriate subject, and not left in bugzilla.
FWIW, there was a dev list thread on this 3 years ago with the subject
mod_deflate and transfer / content encoding problem.
On 12/7/06, Roy T. Fielding [EMAIL PROTECTED] wrote:
Entities gzip:ed by mod_deflate still carries the same ETag as the
plain entiy,
causing inconsistency in ETag aware proxy caches.
I'll have a look later and see if I can fix it, but let me know if there
is already a patch in the works (that
On 12/7/06, Justin Erenkrantz [EMAIL PROTECTED] wrote:
mod_deflate should just add the W/ prefix if it's not already there. -- justin
But, that'll break caches as we're not allowed to serve If-Match with
weak entity tags. Feh.
-1 on adding semantic junk to the existing ETag (and keeping it
39 matches
Mail list logo
