http://issues.apache.org/bugzilla/show_bug.cgi?id=39727
We have some controversy surrounding this bug, and bugzilla
has turned into a technical discussion that belongs here.
Fundamental question: Does a weak ETag preclude (negotiated)
changes to Content-Encoding?
Summary:
Original bug:
)
changes to Content-Encoding?
A weak etag means the response is semantically equivalent both at
protocol and content level, and may be exchanged freely.
Two resource variants with different content-encoding is not
semantically equivalent as the recipient may not be able to understand
an variant sent
On 10/03/2007 03:23 PM, Nick Kew wrote:
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727
We have some controversy surrounding this bug, and bugzilla
has turned into a technical discussion that belongs here.
Fundamental question: Does a weak ETag preclude (negotiated)
changes to
On Oct 3, 2007 7:20 AM, Henrik Nordstrom [EMAIL PROTECTED] wrote:
deflates the contents. Rationale: a weak ETag promises
equivalent but not byte-by-byte identical contents, and
that's exactly what you have with mod_deflate.
I disagree. It's two very different entities.
As before, I still
question: Does a weak ETag preclude (negotiated)
changes to Content-Encoding?
A weak etag means the response is semantically equivalent both at
protocol and content level, and may be exchanged freely.
Two resource variants with different content-encoding is not
semantically equivalent
On Oct 3, 2007, at 7:53 AM, Justin Erenkrantz wrote:
The problem with trying to invent new ETags is that we'll almost
certainly break conditional requests and I find that a total
non-starter. Your suggestion of appending ;gzip leaks information
that doesn't belong in the ETag - as it is quite
On Oct 3, 2007 12:19 PM, Roy T. Fielding [EMAIL PROTECTED] wrote:
I don't see how that is possible, unless subversion is depending
on content-encoding to twiddle between compressed and uncompressed
transfer without changing the etag. In that case, subversion will be
broken, as would any
On Wed, 3 Oct 2007 07:53:31 -0700
Justin Erenkrantz [EMAIL PROTECTED] wrote:
[chop]
The Cc: list on this and subsequent postings is screwed:
(1) It includes me, so I get everything twice.
OK, I can live with that, but it's annoying.
(2) It fails to include Henrik Nordstrom, the
On ons, 2007-10-03 at 07:53 -0700, Justin Erenkrantz wrote:
As before, I still don't understand why Vary is not sufficient to
allow real-world clients to differentiate here. If Squid is ignoring
Vary, then it does so at its own peril - regardless of ETags.
See RFC2616 13.6 Caching Negotiated
On ons, 2007-10-03 at 13:29 -0700, Justin Erenkrantz wrote:
The issue here is that mod_dav_svn generates an ETag (based off rev
num and path) and that ETag can be later used to check for conditional
requests. But, if mod_deflate always strips a 'special' tag from the
ETag (per Henrik),
That
On ons, 2007-10-03 at 12:10 -0700, Roy T. Fielding wrote:
Two resource variants with different content-encoding is not
semantically equivalent as the recipient may not be able to understand
an variant sent with an incompatible encoding.
That is not true. The weak etag is for content
On ons, 2007-10-03 at 21:44 +0100, Nick Kew wrote:
The Cc: list on this and subsequent postings is screwed:
(1) It includes me, so I get everything twice.
OK, I can live with that, but it's annoying.
Use a Message-Id filter?
(2) It fails to include Henrik Nordstrom, the
Henrik Nordstrom wrote:
On ons, 2007-10-03 at 13:29 -0700, Justin Erenkrantz wrote:
The issue here is that mod_dav_svn generates an ETag (based off rev
num and path) and that ETag can be later used to check for conditional
requests. But, if mod_deflate always strips a 'special' tag from the
On ons, 2007-10-03 at 23:52 +0200, Henrik Nordstrom wrote:
That is not HTTP. Don't confuse the needs of caching with the needs
of range requests -- only range requests need strong etags.
I am not. I am talking about If-None-Match, not If-Range. And
specifically the use of If-None-Match in
14 matches
Mail list logo
