On Thursday 29 August 2002 19.16, Michael.Schroepl@telekurs.de wrote:
> >> After all, the Apache admin running mod_gzip has the
> >> option whether he should rather
> >> a) use the "reqheader" directive to support the broken
> >> UserAgents by sending them uncompressed content or
> >> b) ignore the broken UserAgents and serve content that
> >> works best for caching proxies, with a short "Vary"
> >> header, thus supporting the correctly working User-
> >> Agents.
> >> The fewer broken browsers are around, the more likely
> >> it will be that scenario b) will work best.
> >
> > And it will take considerable amount of time before we
> > are there, making it very likely there is ETag support
> > in Squid to address the redundant caching issue.
>
> but aren't we already there for the moment, if
> mod_gzip did sent a "Vary:" header containing the
> complete list of relevant HTTP headers?
At 'b'? Don't think so..
> I haven't yet read all your other mails but I hope
> there is a way to compute this Etag efficiently ...
Yes. Reuse what there already is, and then extend it whenever you gzip
content to make the gzipped entity different from the uncompressed
one.
ETag is basically just a string with the criteria that no two
different reply entities for the same entity have the same ETag
(strong).
There is also something called weak ETags. Entities with differnt
content-encoding may share the same weak ETag, but only if you don't
care which of the encodings the user receives..
> If ETag computation would require having access to
> the result of the request, this would be a problem.
> If mod_gzip did DECLINE in rules evaluation phase 1
> it will not be invoked again after the results are
> there, given its current architecture.
Only adding "gzip" to the already computed ETag is sufficient to make
it differnt from the uncompressed one, provided it can be assumed the
existing ETag engine never can construct such ETags.
> > More technically problemantic to deal with is the If-Match
> > header, and will probably render more or less mod_gzip
> > unuseable on WebDAV enabled servers until solved.. But
> > this too is easy to solve by enforcing a Apahce standard
> > in how ETag should be transformed when the reply entity is.
>
> I didn't fully understand this point.
Perhaps it is easier to understand if we put If-Match into some
context: If-Match is usually used in PUT requests as a validator to
make sure the edited object hasn't been changed. If the object has
changed the PUT request is declined. This has to take place before
the request is processed.
This presents the interesting issue that Apache may need to know about
mod_gzip modified ETags in order to process If-Match correctly.
> > If-None-Match can most likely be processed again by the
> > add-on module. If-None-Match is by nature a fall-thru
> > condition so if the no match was found in the initial
> > check it can be reevaluated later.
>
> I can only hope that this is handled this way by the
> Apache architecture, i. e. it will do nothing special
> in case of some ETag it doesn't know (because mod_gzip
> was the originator).
> We ought to have someone here with a lot more knowledge
> about Apache architecture ...
Well, I can say almost certain that this is the case. If-None-Match is
a fall-thru condition. If it does not match then it is the same as if
the condition wasn't there. Special action only needs to be taken
when a match is found.
> mod_gzip can of course wait until the response arrives,
> then do precondition checking, and possibly throw away
> the results of whatever has happened until then, and
> send HTTP 304 or anything. This would surely not be
> very efficient, but it would not yet provide a deadlock.
Only when you can guarantee the operation does not have any
sideeffects.
PUT is a good example of an operation with quite significant
"sideeffects".
but this is not a major problem for If-None-Match, only If-Match.
The effect of If-Match is likely that a user who has received a
transformed reply entity is likely to end up not being able to
perform the intended operation (PUT or whatever) because the Apache
precondition checking does not know about mod_gzip transformations,
and will deny the reques as there is no apparent match..
> But it cannot make events undone that were caused by
> the evaluation of HTTP requests (like server-side appli-
> cations being executed and changing database contents)
> that shouldn't even have been executed.
Which is a must for If-Match, but not at all critical for
If-None-Match.
> So the problem seems to be a circular dependency bet-
> ween the HTTP request handling and the ETag computation,
> if there is one ... is it?
Yes.
> But compressing dynamic content (like CGI etc.) is another
> story, as there is no sense in caching most of the time.
> (Personally, I have CGI scripts that send "Expires:"
> headers in the future, but they are special cases anyway.)
Very few CGI scripts are likely to use ETag. The exception is CGI
scripts acting as gateways to other data sources.
Regards
Henrik
Received on Thu Aug 29 2002 - 19:56:04 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:16:18 MST