* [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
