[Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=39727

--- Comment #47 from Robert Rothenberg  ---
This is still an issue with Apache 2.4, almost 15 years after this ticket was
created.

It's noteworthy that I came across this bug when looking the Perl
Plack::Middleware::ETag module, which returns malformed ETag headers that are
not quoted.  When using a fixed version of the module, I found tht that Apache
reverse proxy was modifying the ETag headers.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=39727

--- Comment #46 from Henrik Nordstrom  ---
I havet not studied the code in detail, but a note of warning when stripping
information from the etag in if clauses, it is not always straight forward.

For example if you add a nice gzip suffix to the etag when gzip encoding and
then strip this in if-none-match processing then you risk creating the same
problem all over again as you loose the distinction between an identity encoded
variant and an gzip encoded variant.

What you should do is to reconstruct the actual etag the server would have
responded with and then compare this with the if clauses. You may take whatever
shortcuts you like in this process as long as the result is consistent.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=39727

--- Comment #45 from Ebarg  ---
Comment on attachment 18407
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=18407
patch that'll cause mod_filter to unset the etag - see util_filter.h

>Index: mod_deflate.c
>===
>--- mod_deflate.c  (revision 411913)
>+++ mod_deflate.c  (working copy)
>@@ -1088,12 +1088,14 @@
> return rv ;
> }
> 
>+#define PROTO_FLAGS AP_FILTER_PROTO_CHANGE|AP_FILTER_PROTO_CHANGE_LENGTH
> static void register_hooks(apr_pool_t *p)
> {
>-ap_register_output_filter(deflateFilterName, deflate_out_filter, NULL,
>-  AP_FTYPE_CONTENT_SET);
>-ap_register_output_filter("INFLATE", inflate_out_filter, NULL,
>-  AP_FTYPE_RESOURCE-1);
>+ap_register_output_filter_protocol(deflateFilterName, deflate_out_filter,
>+   NULL, AP_FTYPE_CONTENT_SET,
>+   PROTO_FLAGS);
>+ap_register_output_filter_protocol("INFLATE", inflate_out_filter, NULL,
>+   AP_FTYPE_RESOURCE-1, PROTO_FLAGS);
> ap_register_input_filter(deflateFilterName, deflate_in_filter, NULL,
>   AP_FTYPE_CONTENT_SET);
> }

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=39727

--- Comment #44 from Ebarg  ---
Comment on attachment 23051
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=23051
fix etag checking in content handlers by stripping "-gzip" from etags in if
headers

>Index: mod_deflate.c
>===
>--- mod_deflate.c  (revision 729534)
>+++ mod_deflate.c  (working copy)
>@@ -749,6 +760,45 @@
> return APR_SUCCESS;
> }
> 
>+static const char *find_replace(apr_pool_t *pool, const char *s, 
>+const char *pattern, const char *replacement)
>+{
>+const char *result = "", *buffer;
>+const char *pos = s, *match;
>+int offset = strlen(pattern);
>+
>+while((match = strstr(pos, pattern))) {
>+buffer = apr_pstrndup(pool, pos, match - pos);
>+result = apr_pstrcat(pool, result, buffer, replacement, NULL);
>+pos = match + offset;
>+}
>+
>+return apr_pstrcat(pool, result, pos, NULL);
>+}
>+
>+static void fix_header(request_rec *r, const char *header)
>+{
>+const char *value = apr_table_get(r->headers_in, header);
>+const char *new_value;
>+
>+if (value) {
>+new_value = find_replace(r->pool, value, "-gzip\"", "\"");
>+new_value = find_replace(r->pool, new_value, "-gunzip\"", "\"");
>+apr_table_set(r->headers_in, header, new_value);
>+}
>+
>+return;
>+}
>+
>+static int deflate_fixups(request_rec *r)
>+{
>+/* Fix the etags in If-* headers that we transformed */
>+fix_header(r, "If-None-Match");
>+fix_header(r, "If-Match");
>+
>+return OK;
>+}
>+
> /* This is the deflate input filter (inflates).  */
> static apr_status_t deflate_in_filter(ap_filter_t *f,
>   apr_bucket_brigade *bb,
>@@ -1352,6 +1402,7 @@
>   AP_FTYPE_RESOURCE-1);
> ap_register_input_filter(deflateFilterName, deflate_in_filter, NULL,
>   AP_FTYPE_CONTENT_SET);
>+ap_hook_fixups(deflate_fixups, NULL, NULL, APR_HOOK_MIDDLE);
> }
> 
> static const command_rec deflate_filter_cmds[] = {

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=39727

--- Comment #43 from Michael Osipov  ---
I have just reported the very same issue with Tomcat: Bug 63932.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=39727

--- Comment #42 from Arjen de Korte  ---
And again, three years have passed and DeflateAlterETag is available in trunk,
but not in 2.4. What's holding this back? BrotliAlterETag made it into 2.4, so
remarks about not mangling ETag are moot now. It's happening for mod_brotli,
it's about time for mod_deflate too.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=39727

d...@ulupov.com changed:

   What|Removed |Added

 CC|d...@ulupov.com |

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=39727

Szőgyényi Gábor  changed:

   What|Removed |Added

 CC||szg0...@freemail.hu

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=39727

herr.er...@gmail.com changed:

   What|Removed |Added

 CC||herr.er...@gmail.com

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=39727

--- Comment #41 from shmul...@gmail.com ---
I've been going through the comments and some of the links mentioned and I'm
unsure if this issue will be resolved or I should implement a work-around on my
side.

This ticket is open for 9 years now and it is still relevant with apache 2.4.
Is it a WONT FIX ? What's the recent status here for apache users?

Thanks

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=39727

Tim Olsen tol...@alum.mit.edu changed:

   What|Removed |Added

 CC|tol...@alum.mit.edu |

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727

--- Comment #40 from Mark Nottingham m...@mnot.net ---
Just so folks know, the authoritative text on this topic will soon be:
  http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-26

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727

--- Comment #40 from Jackie Rosen jackie.ro...@hushmail.com ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727

--- Comment #39 from Henrik Nordstrom h...@squid-cache.org ---
This has already been discussed to death and still comes back...

There is no escape from the rule that each variant of a given URL MUST have a
unique ETag value, or none at all. How the ETag value is formed is entirely up
ot the server implementation and may carry any amount of unstructured and
structured data as needed by the server to uniquely identify a variant.

Weak ETags have slightly different rules but is irrelevant to this discussion.
Applies i.e. to when using dynamic adjustment of gzip encoding levels based on
CPU load, but not for identity vs gzip encoded variant which are semantically
different.

(In reply to Anshul from comment #38)
 The server response contains proper Vary header clearly indicating the
 response varies depending whether client is able to accept gzip content or
 not.

No. The server has sent a Vary header indicating that the servers variant
selection depends on the content of the Accept-Encoding header in the request,
and quite often User-Agent as well.

 In that case, the responsibility lies with the intermediate proxy to make
 sure all conditional headers check are met before sending a cached response
 for an ETag.

No. It's the origin servers responsibility to perform variant selection. Caches
uses If-None-Match to ask the server which variant among a set of known cached
variants of the requested URL should be used in response to unknown request
combinations. The response to such requests ONLY says Use the variant with
ETag .

Semantically transparent proxies are not allowed to guess what variant
selection preferences the server has. I.e. which browsers it had blacklisted
content of type X for etc, or which browsers the server knows handles gzip
content encoding when there is not Accept-encoding header present.

gzip compression is onlhy a tiny tiny little bit of server side variant
selection. The same mechanism for selecting the correct variant amont a set of
cached variants of a URL is used for a vide variety of response variance
(selection of content-encoding, content-language, content-type, browser based,
custom headers, etc etc)

Note: Apache mod_negotiation does the right thing in all cases known. Issues
only arise with dynamic content encoding with mod_deflate (and a numbe of other
similar modules performing dynamic content transformation) often forgetting
about the meaning of ETag and it's relation to If-None-Match.

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727

--- Comment #38 from Anshul anshulagra...@gmail.com ---
The server response contains proper Vary header clearly indicating the response
varies depending whether client is able to accept gzip content or not.

In that case, the responsibility lies with the intermediate proxy to make sure
all conditional headers check are met before sending a cached response for an
ETag.

For the implications mentioned in the description:
* The repeat request from same client will have same value for
Accept-Encoding header as well as User Agent string meaning Apache has
sufficient information to decide whether to send plain text or gzipped
response. If-None-Match can have same ETag value in both case and still server
should have no problem deciding which response to send.

* The above logic covers range queries as well.

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727

rob...@robduncan.co.uk changed:

   What|Removed |Added

 CC||rob...@robduncan.co.uk

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727

--- Comment #37 from Andrey Chernov a...@vniz.net ---
Since different gzip compression levels are semantically equal, you can
_always_ send weak tag when using gzip with any compression level, with -gzip
suffix like that:

ETag: W/76e23-1835-4156af5e53ac0-gzip

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727

Andrey Chernov a...@vniz.net changed:

   What|Removed |Added

 CC||a...@vniz.net

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727

Ian Brandt i...@ianbrandt.com changed:

   What|Removed |Added

 CC||i...@ianbrandt.com

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727

--- Comment #36 from Oliver Siegmar oli...@siegmar.net 2011-09-14 11:51:55 
UTC ---
Any news about this more than five years old bug?

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727

Oliver Siegmar oli...@siegmar.net changed:

   What|Removed |Added

 CC||oli...@siegmar.net

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727

Rainer Jung rainer.j...@kippdata.de changed:

   What|Removed |Added

 CC||apa...@misc.lka.org.lu

--- Comment #35 from Rainer Jung rainer.j...@kippdata.de 2010-05-29 08:25:05 
EDT ---
*** Bug 49358 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727

--- Comment #34 from Robert Collins robert.coll...@canonical.com 2010-05-18 
17:42:42 EDT ---
We're encountering this problem using Apache as a front end SSL / compressing
accelerator. Is there any chance of getting a patch in to permit stripping
incoming ETag's of their -gzip suffix based on a configuration option ? In our
topology we know precisely where -gzip is added, and thus how to strip it
safely; we'd rather strip it in the stage matching where it was added outbound,
rather than at a different step.

I realise that this isn't theoretically complete, but crucially for us, it
would do the job reliably.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727

Robert Collins robert.coll...@canonical.com changed:

   What|Removed |Added

 CC||robert.coll...@canonical.co
   ||m

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727





--- Comment #33 from Edgar Ehritt e.ehr...@web.de  2009-05-23 05:22:29 PST ---
Hi,


I refer to https://issues.apache.org/bugzilla/show_bug.cgi?id=47253 . In
this situation imho fixing it this way is retrograde step. There is a
question I would like to ask here:

Why you do not determined a policy?

   - Etag will formed as usual.
   - Configuration tree, that handle a resource, add fourth digest part
 into Etag-values.
   - Each filter transforming contents (on-the-fly) have to add a suffix.

I imagine, each handler have a unique key (let's say mod_deflate DE and
mod_include IN etc.). Configuration tree means a string consisting of
all keys [ simple: next = etag_uint64_to_hex(next, IN:CH:DE); ]. So a
change of configurations will be unique in Etag as well. But sensible
configuration information should encodet twice (first time nonreversible
by including a static unique-ID of environment) to withhold clients from
it. Already configuration tree is being parsed. It means there is a small
overhead in prucedures like that.

https://svn.apache.org/viewcvs.cgi?view=revrev=761835 it works fine befor
change. Only you should remove all added suffixes, then check condition
requests. Befor Etag-value are comprised that way:
%{resource_digest}-suffix
Only check %{resource_digest}. (modules/http/http_protocol.c; function
ap_meets_conditions(); line 270)

The worse is yet to come:
I see now way to determine mod_ext_filter. Handler module should remove
all symbols form responce header line Cache-Control how make it cache
able, and maybe statically add symbols to force inability.

I'm sorry. English is not my nativ language. ;-\


With best regards from Berlin
eddi

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727


Edgar Ehritt e.ehr...@web.de changed:

   What|Removed |Added

 Blocks||47253




-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727


d...@ulupov.com changed:

   What|Removed |Added

 CC||d...@ulupov.com




-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727


Taco van den Broek taco.vandenbr...@procurios.nl changed:

   What|Removed |Added

 CC||taco.vandenbr...@procurios.
   ||nl




-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727


Roy T. Fielding field...@apache.org changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED




--- Comment #31 from Roy T. Fielding field...@apache.org  2009-02-12 17:08:56 
PST ---
The HTTP syntax error has been fixed in trunk, but the problem
motivating this report is a no-win situation no matter how it is
fixed.  The only good answer is don't use mod_deflate because
changing content-encoding on the fly in an inconsistent manner
(neither never nor always) makes it impossible for later
requests regarding that content (e.g., PUT or conditional GET)
to be handled correctly.  This is, of course, why performing
on-the-fly content-encoding is a stupid idea, and why I added
Transfer-Encoding to HTTP as the proper way to do on-the-fly
encoding without changing the resource.

mod_deflate is written as a content filter that can be arbitrarily
added to the output chain after the request is processed, just
before the body goes out on the wire.  If mod_deflate modifies
ETag on the way out, then its corresponding later requests must
be reverse-modified (etags and request content) on the way back.

The problem here is that the DEFLATE filter is usually
added after the request is processed, based on the media type
of the response, so there is no clear way of selectively inflating
a corresponding PUT or conditional request before the request
processing is begun, especially if the request has been
proxied to another server.  We would have to add a corresponding
input filter whenever the output filter is configured and ensure
that it would activate under the same conditions, based on the
request header fields, as DEFLATE/INFLATE does for responses.
I am still looking at this option.

Preprocessing all incoming conditional headers to remove
a -gzip suffix before the request is processed won't work.
In a chain of Apache servers, we won't know which server
set the suffix and how many caches have stored the modified
ETag versus the unmodified ETag.  We can't add some random
unique id to the suffix, either, since we need the tag to
persist across restarts.  In any case, that solution becomes
so complex that we are better off deleting the module.

Finally, we can't just remove the ETag because then the
unfiltered content has an ETag but the filtered content
does not, which puts us back to the point of messing up
a cache that is checking the 304 response for consistency.
Likewise, removing etags for the entire configured scope
allows clients to use the last-modified timestamp for range
requests, which would be just as bad as not changing ETag.

The best solution is to implement transfer-encoding as an
http protocol filter module.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727





--- Comment #32 from Henrik Nordstrom h...@squid-cache.org  2009-02-12 
18:42:13 PST ---
Deleting the ETag+Content-Location is safe with respect to caches even if very
suboptimal in terms of HTTP performance and cache validation robustness. It's
highly undesireable, but still better than sending out the same ETag or
Content-Location on incompatible respones.

Sending responses with an ETag and/or Content-Location which MAY be shared by
an incompatible response for the same URL makes a true mess for caches. This
applies to both 200 and 304 responses. The mess gets injected by the processing
of 304 responses which may make incompatible but identified equal content
migrate between different requeests.

And yes, Roy is absolutely right. HTTP is not well suited for on-the-fly
content recoding. You can't both eat the cake and keep it unless you do a lot
of effort, far beyond the recoding itself. To anyone external from the server
it SHOULD look like the recoding is in fact done statically with different
representations stored on the server (i.e. page.html and page.html.gz) as
negotiated by mod_negotiate, That means unique ETags and unique
Content-Location, plus the If-* conditions working properly for all
combinations.

Not impossible, but not easy either.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727





--- Comment #26 from Henrik Nordstrom h...@squid-cache.org  2009-02-03 
00:24:45 PST ---
What do you mean by ignore weak etags?

If there is a weak ETag then it needs to be transformed as well, or removed. If
not you'll still crash caches out there as object variants is identified by
their ETag.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727





--- Comment #30 from Henrik Nordstrom h...@squid-cache.org  2009-02-03 
06:23:55 PST ---
Just to clarify the breakage:

GET /some-object

HTTP/1.1 200 OK
Vary: Accept-Encoding
ETag: W/a

GET /some-object
Accept-Encoding: gzip
If-None-Match: W/a

HTTP/1.1 304 Not Modified
ETag: W/a


If you are unsure what this is about, see 13.6  Caching Negotiated Responses.


To explain it in other words: Two resource versions MAY share the same weak
ETag (but MUST NOT when using a strong ETag), but two incompatible resource
representations MUST NOT.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727





--- Comment #29 from Henrik Nordstrom h...@squid-cache.org  2009-02-03 
06:17:14 PST ---
A weak ETag means the two are interchangeable for the same request
(semantically equivalent) but may differ significantly at the octet level.

A gzip and identity encoded entity is not interchangeable without serious
breakage.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727





--- Comment #28 from Lars Eilebrecht l...@apache.org  2009-02-03 04:34:33 PST 
---
(In reply to comment #26)
 What do you mean by ignore weak etags?

Well, the original code was only adding the gzip marker when the
Etag was not starting with W/, and I didn't changed this behavior.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727





--- Comment #27 from Ruediger Pluem rpl...@apache.org  2009-02-03 03:13:08 
PST ---
(In reply to comment #26)
 What do you mean by ignore weak etags?
 
 If there is a weak ETag then it needs to be transformed as well, or removed. 
 If
 not you'll still crash caches out there as object variants is identified by
 their ETag.
 

This is discussible. A weak ETAG IMHO doesn't mean that both entities with the
same weak ETAG are the same on binary level. But the weak ETAG only changes
when the meaning of the entity changes (13.3.3, 3rd paragraph).


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727


Lars Eilebrecht l...@apache.org changed:

   What|Removed |Added

 CC||l...@apache.org




--- Comment #25 from Lars Eilebrecht l...@apache.org  2009-02-02 15:27:04 PST 
---
Committed patch to trunk fixing the creation of invalid Etag headers
such as 

  Etag: 2106e9-2c-3e9564c23b60-gzip

instead of 

  Etag: 2106e9-2c-3e9564c23b60-gzip

mod_deflate ignores invalid Etag headers not starting with a double quote,
and weak Etag headers starting with W/. 

http://svn.apache.org/viewvc?view=revrevision=740149


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727





--- Comment #24 from Paritosh Shah shah.parit...@gmail.com  2008-12-26 
13:32:50 PST ---
Created an attachment (id=23051)
 -- (https://issues.apache.org/bugzilla/attachment.cgi?id=23051)
fix etag checking in content handlers by stripping -gzip from etags in if
headers

A problem with adding -gzip to etags is that it breaks etag checking in If-*
headers for content handlers ( e.g. mod_dav ) which will not recognize the
-gzip etag as a valid etag for any entity of the resource. One way to fix
this is to strip the -gzip suffix from the etags in If-None-Match and
If-Match request headers. Attaching a patch to achieve this. It implements a
fixup hook in mod_deflate and fixes etags in the respective headers. The patch
has been tested with mod_dav_fs for If-Match and If-None-Match headers, with
and without gzip encoding.

Note: this patch depends on the previous patch
(https://issues.apache.org/bugzilla/attachment.cgi?id=23050) having already
been applied.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727





--- Comment #23 from Paritosh Shah shah.parit...@gmail.com  2008-12-24 
14:59:45 PST ---
Created an attachment (id=23050)
 -- (https://issues.apache.org/bugzilla/attachment.cgi?id=23050)
patch that fixes the etags transformed by mod_deflate to be quoted strings

Addresses the issue raised by Maxime Ritter - currently the Etags that are
transformed by mod_deflate are not properly quoted and are not RFC compliant.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727


Paritosh Shah [EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727


Tim Olsen [EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727


Franklin Tse [EMAIL PROTECTED] changed:

   What|Removed |Added

 Blocks||45023




-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727


Franklin Tse [EMAIL PROTECTED] changed:

   What|Removed |Added

   Keywords||RFC
 OS/Version|other   |All
   Platform|Other   |All
Version|2.2.2   |2.2.8




-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727


Franklin Tse [EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727


Sidharth Kshatriya [EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727


Maxime Ritter [EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]
 Status|RESOLVED|REOPENED
 Resolution|FIXED   |




--- Comment #22 from Maxime Ritter [EMAIL PROTECTED]  2008-09-11 06:00:58 PST 
---
This fix needs improvements. Etag needs to be quoted ;  this fix adds -gzip
outside the quotes, so I get things like 638f3e-6-1b6d6340-gzip which is
ugly and not very RFC compliant.

Now, another problem I got. I have 2 servers with mod_deflate and mod_cache.
with mod_cache, I get validation 

- If behind the same squid proxy I have servers with DeflateCompressionLevel
set to 1, and other ones with DeflateCompressionLevel 7, and mod_cache enabled
on get validation on different contents.
(yes, I know that's a change strange setup).


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727


Chris Woodfield [EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Bug 39727] Incorrect ETag on gzip:ed content

[bugzilla]

http://issues.apache.org/bugzilla/show_bug.cgi?id=39727


Takashi Sato [EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Keywords|FixedInTrunk|
 Resolution||FIXED




--- Comment #21 from Takashi Sato [EMAIL PROTECTED]  2008-02-27 04:49:12 ---
http://svn.apache.org/viewvc?view=revrevision=581198
http://svn.apache.org/viewvc?view=revrevision=607219


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] - Incorrect ETag on gzip:ed content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39727





--- Additional Comments From [EMAIL PROTECTED]  2008-01-19 09:29 ---
2.2 r608849
http://svn.apache.org/viewvc?view=revrevision=608849

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] - Incorrect ETag on gzip:ed content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39727


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] - Incorrect ETag on gzip:ed content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39727





--- Additional Comments From [EMAIL PROTECTED]  2007-10-03 05:18 ---
(In reply to comment #18)
 (In reply to comment #17)
 
  Only a recipient that can handle gzip will be served the gzipped version.
 
 Which isn't true due to this bug. If there is a ETag aware cache between the
 client and Apache the client will be given whatever the previous client could
 handle.

The intermediate got a weak ETag.  So the intermediate has been told that the
entity is equivalent but not byte-by-byte identical, and may be subject to
negotiated transformation.  Therefore the intermediate is responsible for
dealing with content-negotiated properties.

Do you have a particular intermediate in mind, when you propose something that
treats a weak ETag as strong?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] - Incorrect ETag on gzip:ed content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39727


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] - Incorrect ETag on gzip:ed content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39727


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Keywords||FixedInTrunk




--- Additional Comments From [EMAIL PROTECTED]  2007-10-02 04:52 ---
Just committed a fix to make any ETag weak if we transform the entity. 
Hopefully this should fix protocol compliance (and our users) without being
controversial.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] - Incorrect ETag on gzip:ed content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39727





--- Additional Comments From [EMAIL PROTECTED]  2007-10-02 11:30 ---
Not sufficient. The two versions is not semantically equivalen as one can not be
exchanged for the other without breaking the protocol. In the context of
If-None-Match the weak comparator is used in HTTP and there a strong ETag is
equal to a weak ETag.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] - Incorrect ETag on gzip:ed content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39727





--- Additional Comments From [EMAIL PROTECTED]  2007-10-02 11:51 ---
Can you elaborate in more detail why you think that the two versions are not
semantically equivalent? I read 13.3.3 in a way that they are.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] - Incorrect ETag on gzip:ed content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39727





--- Additional Comments From [EMAIL PROTECTED]  2007-10-02 12:22 ---
Because you can not exchange the gzip:ed variant with the identity encoded
variant wihout causing breakage. The two do not mean the same thing to a
recipient who do not know how to handle gzip.

The two is only semantically equivalent for a recipient capable of handling
gzip, but not to HTTP in general as HTTP do not guarantee clients can handle 
gzip.

If they were semantically equivalent then there would be no need for conditional
mod_gzip compression, or the use of Vary, at least not other than to reduce the
load on the server under peak load...

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] - Incorrect ETag on gzip:ed content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39727





--- Additional Comments From [EMAIL PROTECTED]  2007-10-02 12:30 ---
What you can do is to either

a) Drop the ETag completely. This is not opimal but works..

b) Or modify the ETag value in some manner. For example adding a constant string
infront or after the original ETag.

In 'b', if the compression is not deterministic and always resulting in the same
encoding then the ETag should additionally be made weak, to make sure no one
attemtps merging partial responses down the line..



The main downside of 'a' is that ETag aware caches will then cache multiple
copies of the same object, one per each slight varance of Vary indicated
headers. For Apache itself it's not so big difference until conditional requests
works proper in precense of filters like mod_deflate (i.e. If-None-Match).

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] - Incorrect ETag on gzip:ed content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39727





--- Additional Comments From [EMAIL PROTECTED]  2007-10-02 12:54 ---
(In reply to comment #15)
 Because you can not exchange the gzip:ed variant with the identity encoded
 variant wihout causing breakage. The two do not mean the same thing to a
 recipient who do not know how to handle gzip.

Bugzilla is the wrong place for this discussion.  Should be on [EMAIL PROTECTED]

Only a recipient that can handle gzip will be served the gzipped version.

 The two is only semantically equivalent for a recipient capable of handling
 gzip, but not to HTTP in general as HTTP do not guarantee clients can handle 
 gzip.

HTTP provides a separate mechanism for negotiating that.

 
 If they were semantically equivalent then there would be no need for 
 conditional
 mod_gzip compression, or the use of Vary, at least not other than to reduce 
 the
 load on the server under peak load...

Huh?  Those exist precisely because we need to cater for different clients.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] - Incorrect ETag on gzip:ed content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39727





--- Additional Comments From [EMAIL PROTECTED]  2007-10-02 15:10 ---
(In reply to comment #17)

 Only a recipient that can handle gzip will be served the gzipped version.

Which isn't true due to this bug. If there is a ETag aware cache between the
client and Apache the client will be given whatever the previous client could
handle.

 Huh?  Those exist precisely because we need to cater for different clients.

Exactly.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] - Incorrect ETag on gzip:ed content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39727





--- Additional Comments From [EMAIL PROTECTED]  2007-08-27 05:25 ---
Pinging dev@ one more time..

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] - Incorrect ETag on gzip:ed content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39727


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] - Incorrect ETag on gzip:ed content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39727





--- Additional Comments From [EMAIL PROTECTED]  2006-12-07 14:19 ---
My suggestion is to simply extend the existing etag with a gzip marker, for
example adding ;gzip at the end or something like that.

I.e. if the original reply had

ETag: 6bf1f7-6-1b6d6340

Then make mod-gzip translate this to

ETag: 6bf1f7-6-1b6d6340;gzip

This should allows for easy bidirectional mapping, simplifying most conditionals
as no transformation of the entity body is needed to find the etag, and the
simple format makes it easier to trace should any misunderstandings occur.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] - Incorrect ETag on gzip:ed content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39727


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Priority|P2  |P1




--- Additional Comments From [EMAIL PROTECTED]  2006-12-06 16:30 ---
This needs to be fixed by mod_deflate producing a new etag.  How we do that
is going to take some investigation, since it doesn't do any good to produce
the etag unless we can also check it on conditional requests.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] - Incorrect ETag on gzip:ed content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39727





--- Additional Comments From [EMAIL PROTECTED]  2006-11-20 01:11 ---
Any progress on getting this patch (or another reasonable alternative) into the
mod_deflate tree?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] - Incorrect ETag on gzip:ed content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39727





--- Additional Comments From [EMAIL PROTECTED]  2006-06-06 08:51 ---
Some references

My ETag notes:  http://devel.squid-cache.org/

Old dev discussions:
http://mail-archives.apache.org/mod_mbox/httpd-dev/200311.mbox/[EMAIL PROTECTED]
http://mail-archives.apache.org/mod_mbox/httpd-dev/200311.mbox/[EMAIL PROTECTED]
http://mail-archives.apache.org/mod_mbox/httpd-dev/200206.mbox/[EMAIL PROTECTED]

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] - Incorrect ETag on gzip:ed content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39727





--- Additional Comments From [EMAIL PROTECTED]  2006-06-06 20:49 ---
(In reply to comment #1)
 Created an attachment (id=18407)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=18407action=view) 
[edit]
 patch that'll cause mod_filter to unset the etag - see util_filter.h
 
 This needs more discussion before committing this or any other patch.

Sorry for my confusion, but this will only work if mod_deflate is used via
mod_filter, right?
It will not work if mod_deflate is used without mod_filter. I guess for this
case it is needed to unset the ETag header inside mod_deflate. So something like
the following:

Index: mod_deflate.c
===
--- mod_deflate.c   (Revision 411469)
+++ mod_deflate.c   (Arbeitskopie)
@@ -389,6 +389,7 @@
 apr_table_mergen(r-headers_out, Content-Encoding, gzip);
 }
 apr_table_unset(r-headers_out, Content-Length);
+apr_table_unset(r-headers_out, ETag);

 /* initialize deflate output buffer */
 ctx-stream.next_out = ctx-buffer;

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] - Incorrect ETag on gzip:ed content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39727





--- Additional Comments From [EMAIL PROTECTED]  2006-06-06 21:40 ---
(In reply to comment #3)

 Sorry for my confusion, but this will only work if mod_deflate is used via
 mod_filter, right?

Yes.  I mentioned that to the reporter in IRC, but not here,

  apr_table_unset(r-headers_out, Content-Length);
 +apr_table_unset(r-headers_out, ETag);

Ugh.  That way every filter has to reinvent protocol handling.  A fertile 
breeding ground for bugs (and we have a history to prove it).  mod_filter is 
designed to centralise that, so we only need to get the protocol right once.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] - Incorrect ETag on gzip:ed content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39727





--- Additional Comments From [EMAIL PROTECTED]  2006-06-06 22:02 ---
(In reply to comment #4)
   apr_table_unset(r-headers_out, Content-Length);
  +apr_table_unset(r-headers_out, ETag);
 
 Ugh.  That way every filter has to reinvent protocol handling.  A fertile 
 breeding ground for bugs (and we have a history to prove it).  mod_filter is

Yes, and I am pretty sure we have this history :-), BUT mod_filter is not
mandatory to use.
 
 designed to centralise that, so we only need to get the protocol right once.

Agreed, but then we must make the use of mod_filter (or at least the usage of
these parts) mandatory or must incorporate them into the core filter routines.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] - Incorrect ETag on gzip:ed content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39727





--- Additional Comments From [EMAIL PROTECTED]  2006-06-07 03:57 ---
From a protocol perspective removing the ETag is sufficient to make you
compliant. If conditionals (If-xxx) anyway doesn't work right on transformed
responses there is not much benefit of sending an ETag out.

But if you can it's better if you send an ETag. As I said initially you don't
need  to compute a new etag, just adding some extra detail to the tag is fine.

I.e. 638f3e-6-1b6d6340-gzip or similar for a gzip:ed entity where the base
entity had the etag 638f3e-6-1b6d6340.  To HTTP the etag is just a string with
the only requirement that it must be unique for each entity variants of the same
URL.

Actually I think adding details to the ETag may simplify many things for you as
the core routines then can make quick asments of conditionals if it's
possible to infer information about how the object had been processed from
looking at the entity tag.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39727] - Incorrect ETag on gzip:ed content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39727





--- Additional Comments From [EMAIL PROTECTED]  2006-06-06 00:43 ---
Created an attachment (id=18407)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=18407action=view)
patch that'll cause mod_filter to unset the etag - see util_filter.h

This needs more discussion before committing this or any other patch.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]