httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Malo ...@perlig.de>
Subject Re: [Review] mod_deflate.xml (Revision)
Date Wed, 27 Nov 2002 05:38:16 GMT
* Michael.Schroepl@telekurs.de wrote:

> Yes, you named it below. I just wondered whether to mention
> Netscape 4 explicitly already in this early section, maybe
> with a local link to the later target.

I think with the current structure (example for the impatient, blah) this 
is ok.

> (Actually, Netscape 4.06 seems to be the version when they
> added the gzip support, possibly together with PNG support;
> Netscape 4.03 doesn't send "Accept-Encoding" at all, and I
> even remember some customer using 4.04 not supporting gzip.)

If no Accept-Encoding header is received, everything is fine ;-)

>>>> you may use the AddOutputFilterByType directive.
>>> You might add a note about this being a valid alternative to
>>> excluding Netscape 4.
> The point is that Netscape 4.[5-8].* _can_ render gzipped _HTML_
> content reasonably well [1], which makes up for the main part
> of the traffic when you only look at MIME types that are worth
> being compressed (HTML, CSS and JS), i. e. disregarding graphics
> and most binary stuff.
[...]
> would just be the next logical step: A compressed CSS file being
> part of a compressed HTML content is often smaller than a HTTP
> response header with the 304 status.
[...]

yep. This is all interesting for the user, but IMHO also too much for a 
module descrition. Thatswhy I'd favor a compression howto :)

>> <http://httpd.apache.org/docs-2.0/mod/mod_expires.html>

> Sure, I am using (the 1.3 version of) it excessively.
> But you know how users configure their browsers? :-(

hmm. that's their decision. I'd tend to leave it at the client side. A 
server is only (and should only be) able to give *hints*. That principle is 
knocked out by your system (i.e. you take over a decision, that's not 
yours).

> Netscape 4 did trust the "Expires" headers without hesitation,
> even if you set its caching strategy to "validate always". ;-)
> The modern browsers overrule this, which may lead to a flood
> of HTTP 304 responses if they have "validate always" selected.

I had never problems with shift+reload ;-)

>> hmm, what can a server admin actually do?
>> (possible variant:
>> BrowserMatch \bMSIE MSIE
>> SetEnvIf http_version HTTP/1.0 waah
>> ...
>> <!--#if expr="$MSIE && $waah" -->
>> Enable HTTP/1.1 for compression
>> <!--#endif -->
>> )
> 
> Unfortunately this won't even work.
> 
> The server can detect the HTTP level of the incoming request.
> But it cannot detect the HTTP level of the request being sent
> by the browser in the first place! There might be proxies in
> between forwarding a HTTP/1.1 request to a HTTP/1.0 request.
> I am running a transparent Netscape proxy doing just that. :-(

uh, yes. overlooked such a combination...

> But "MSIE understanding gzip" is bundeled together with "MSIE
> _trying_ to speak HTTP/1.1" - not with actually _doing_ it ...

right. only think of the content-type guessing game... ;-)

>> If someone writes a compression howto, that would be appropriate.
>> Hmm... seriously: Are you interested in writing such a document?
> 
> Is there any requirement list what such a paper would include,
> and from which point of view the matter had to be described?

It should be useful and easy to understand, that's all ;)
Something like the documents in <http://httpd.apache.org/docs-2.0/howto/>.

>>> Or maybe just a note how to check whether this header actually
>>> arrived from the browser ... I remember the log definitions
>>> provide for HTTP request headers being accessible like
>>> "%{Accept-Encoding}i", at least this worked for Apache 1.3. ;-)
>> That's documented in mod_log_config.xml.
> 
> What about adding some link from here to there?

I think, I'll include it in the "deflate" log format example. That should 
be sufficient (perhaps + see also mod_log_config)

> There are a lot of situations where you have to decide whether
> to support broken foreign software or not. In this special
> case it would have to be done at the expense of the vast
> majority of the other browsers who correctly support the
> standard. There might be more than one opinion about that.

Certainly. But an official reference manual should be free from "opinions". 
It may "recommend" how to configure a stable running server with most 
compatibility. (the deflate stuff is not the only downgrade/compat action. 
hehe...for example, the funny "X-Pad: avoid browser bug" is also still 
alive somewhere in the core)

> And no, a "Vary:" with only "Accept-Encoding" is far from
> being worthless ... it would protect a lot of browsers (like
> the MSIE running in HTTP/1.0 mode) from gzipped content,
> while in fact not protecting _all_ of them (like Netscape 4).
> Every bit can help and prevent potential problems.
> If you have a broken proxy in the game that ignores "Vary:"
> headers (like a customer of ours with some Microsoft Proxy
> running with installation defaults), you are lost anyway.

But I guess that's not the only problem with such braindead software...

> By the way: Is a compressed version of a content still con-
> sidered to be the same "HTTP entity"?
> I am asking because I am not sure whether gzipping the content
> should make Apache create some different "ETag:" as well ...
> the RFC 2616 isn't very informative to me about this aspect,
> and the Squid developers suggested me to consider doing this
> (maybe just add some extension to the existing ETag, to make
> it unique again - would that rather help or hurt?).

Good point. I read (again ;-) some sections in RFC 2616 and found:

14.11 Content-Encoding

   The Content-Encoding entity-header field is used as a modifier to the
   media-type.
   [...]
   The content-coding is a characteristic of the entity identified by
   the Request-URI. [...]

*kaboom*. If I understand that correctly, it's *wrong* to serve compressed 
content under the same URI (and the same *entity*-tag-header). It seems, 
dynamic compression should be noted in Transfer-Encoding. And... I guess in 
that case it must not (or should not?) be noted in Vary:.

hmm...???

> Part of the "consideration" process is done in mod_gzip by
> configuring lower and upper bounds for the size of content
> to be compressed: With very small files, you won't gain a
> lot in absolute terms, and with very large files, you may
> cause load peaks and delays for serving then compressed
> content.

hmm. upper bound is not very applicable, because of the filter architecture 
of mod_deflate. The lower bound could be made configurable between 0 and 
one bucket-brigade-size (8KB), similar to the Content-length filter.

>>> Viele Grüße
>> ;-)
> 
> I got used to this from some other mailing list where I have
> to respond in English to people whom I feel can read/write
> German much more fluently - this might encourage them to mail
> me in German in case they have problems describing their
> case in English ... somehow similar to your signature.

*grin* if the people would write their emails in perl it would be easy...

however, for the compression-howto we should perhaps mail in german, it's 
more easy to understand *g*. you know my address...

nd
-- 
$_=q?tvc!uif)%*|#Bopuifs!A`#~tvc!Xibu)%*|qsjou#Kvtu!A`#~tvc!KBQI!)*|~
tvc!ifmm)%*|#Qfsm!A`#~tvc!jt)%*|(Ibdlfs(~  # What the hell is JAPH? ;
@_=split/\s\s+#/;$_=(join''=>map{chr(ord(  #             André Malo ;
$_)-1)}split//=>$_[0]).$_[1];s s.*s$_see;  #  http://www.perlig.de/ ;

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org


Mime
View raw message