On Wednesday 28 August 2002 22.48, 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.
> If I get it right, then the requirements made by Squid
> 2.6 for mod_gzip and Apache are of the type that if
> compression via negotiation is in use, so that an URI
> will generally be mapped to a set of (exactly two)
> entities with different ETags, then the whole HTTP
> handling of the Apache would have to take that into
> consideration.
Quite likely.
> Doing any "If-None-Match" processing seems to first
> of all require Apache to compute these two possible
> ETag values and check which of the possible cases in
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.26
> applies. This would have to be done even before the
> request would have to be handled, whose output would
> much later become an input into mod_gzip as to in-
> spect whether it should be compressed or not.
Yes. Interesting problem to solve. But for Squid's purposes it is
sufficient if mod_gzip detects the If-None-Match and if a match is
found with the current etag (after mod_gzip transformation has been
accounted for) change the reply to a 304. Sure, it is not the most
optimal approach to If-None-Match in precense of transformations such
as mod_gzip, but most likely very easy to implement.
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.
If-Range also presents a bit of the same problem, but is not as
problematic as it can be ignored and the response will still be
correct even if not optimal.
> So if the requirement for _Apache_ would be to handle
> If-None-Match then I believe the code positions to do
> so would be far away from the code that currently
> makes up mod_gzip.
If mod_gzip is to play nicely with caches to avoid excessive redundant
storage of the same object then If-None-Match will need to be
supported.
> On the other hand, Apache 1.3.26 _does_ already have
> some "If-None-Match" support.
> The source code file "main/http_protocol.c" contains
> a lot of stuff that seems to handle the "If-None-Match"
> thing.
I know. Used it as one of the test targets while developing
If-None-Match support for Squid.
> /* If an If-None-Match request-header field was given
> * AND the field value is "*" (meaning match anything)
> * OR our ETag matches any of the entity tags in that
> field, fail. *
And the key for this piece of code to operate correctly is to have
access to the ETag of the reply entity.
> So if I didn't miss some important point, my conclusion
> would be: If the correct use of Content-Encoding accor-
> ding to HTTP/1.1 would require Apache to change its
> basic HTTP behaviour, like now handling "If-None-Match"
> headers differently and being aware of two separate en-
> tities with separate Etags, then it might be rather
> difficult to do this outside the Apache core by some
> add-on module.
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.
What to watch out for is to ensure that If-None-Match does not cause
false negotiation responses, indicating that the user should be sent
the "original" uncompressed entity. Fortunately it is likely to error
on the safe side if there is problems so it is only likely to be a
minor nuicanse.
If-Match is worse, but not something I personally care about (not
relevant to caches).
> Or it might imply that some future mod_gzip version
> trying to meet the requirements of Squid 2.6 would
> need to patch the Apache core.
I see it more likely that this future mod_gzip version may need to
duplicate some of the functions also performed by the core to
compensate for the fact that the conditions have changed.
> But if I now learn that the whole Content-Encoding
> business is much more than just negotiating some
> "Accept-Encoding" header and compressing a buffer
> content, but needs the whole HTTP processing to know
> about the existance of two related entities, then I
> don't understand any more how the Apache Group would
> ever have planned to solve issues like the one we are
> discussing about. After all, they are shipping some
> mod_deflate themselves.
>
> I really _hope_ that I have failed to understand
> something on the way to this point ...
I am afraid not..
Applying entity transformations has implications on ETag, and
therefore has direct implications on HTTP preconditions, resulting in
a deadlock as mod_gzip cannot correctly evaluate the response until
the response exists, and the action resulting in the response is not
allowed to be taken before the preconditions have been evaluated.
But as I said above it isn't this bad for the If-None-Match condition.
It can most likely be dealt with in reasonable manners anyway
assuming a response filter such as mod_gzip is allowed to replace the
response by another response.
Regards
Henrik
Received on Wed Aug 28 2002 - 18:39:21 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:16:16 MST