Re: mod_cache, mod_deflate and Vary: User-Agent
> Brian Akins of Turner Broadcasting, Inc. wrote... > > We are moving towards the 'if you say you support gzip, > then you get gzip' attitude. There isn't a browser in the world that can 'Accept Encoding' successfully for ALL mime types. Some are better than others but there are always certain mime types that should never be returned with any 'Content Encoding' regardless of what the browser is saying. In that sense, you can never really trust the 'Accept-encoding: gzip, deflate' header at all. There is (currently) no mechanism in the HTTP protocol for a client to specify WHICH mime types it can successfully decode. It was supposed to be an 'all or nothing' DEVCAP indicator but that's not how things have evolved in the real world. There are really only 3 choices... 1. Stick with the original spec and continue to treat 'Accept-encoding: whatever' as an 'all or nothing' indicator with regards to possible mime types and treat every complaint of breakage as 'it's not our problem, your browser is non-compliant'. 2. Change the original spec and add a way for clients to indicate which mime types can be successfully decoded and then wait for all the resulting support code to be added to all Servers and Proxies. 3. Do nothing, and let every individual Server owner continue to find their own solution(s) to the problem(s). Yours Kevin Kiley -Original Message- From: Akins, Brian To: dev@httpd.apache.org Sent: Thu, Aug 27, 2009 9:42 am Subject: Re: mod_cache, mod_deflate and Vary: User-Agent On 8/26/09 3:20 PM, "Paul Querna" wrote: > I would write little lua scriptlets that map user agents to two > buckets: supports gzip, doesnt support gzip. store the thing in > mod_cache only twice, instead of once for every user agent. We do the same basic thing. We are moving towards the "if you say you support gzip, then you get gzip" attitude. I think less than 1% of our clients would be affected, and I think a lot of those are fake agents anyway. -- Brian Akins
Re: svn commit: r808489 - /httpd/httpd/branches/2.2.x/docs/manual/mod/mod_proxy.xml
Ruediger Pluem wrote: On 08/27/2009 06:18 PM, n...@apache.org wrote: Author: niq Date: Thu Aug 27 16:18:19 2009 New Revision: 808489 URL: http://svn.apache.org/viewvc?rev=808489&view=rev Log: Improve docs note on PR 46665 (ProxyPassMatch buglet) as suggested by wrowe Don't you need to do these changes in the trunk doc as well to fix r808321? Was holding off in case of any further comments that might provoke another update. And because I've been out for the evening. -- Nick Kew
Re: svn commit: r808212 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_cache.xml modules/cache/cache_storage.c modules/cache/cache_util.c modules/cache/mod_cache.c modules/cache/mod_cache.h
Ruediger Pluem wrote:
> The original code above uses some magic to avoid stomping on an already
> existing Warning header:
>
> /* make sure we don't stomp on a previous warning */
> if ((warn_head == NULL) ||
> ((warn_head != NULL) && (ap_strstr_c(warn_head, "110") ==
> NULL))
> ) {
> apr_table_merge(h->resp_hdrs, "Warning",
> "110 Response is stale");
>
> Shouldn't we do the same thing here as well?
The nett effect is that we'll have two warnings, which is in theory
harmless, but consistency is good.
r808656.
>> +/* try to obtain a cache lock at this point. if we succeed,
>> + * we are the first to try and cache this url. if we fail,
>> + * it means someone else is already trying to cache this
>> + * url, and we should just let the request through to the
>> + * backend without any attempt to cache. this stops
>> + * duplicated simultaneous attempts to cache an entity.
>> */
>> -if (r->main) {
>> -ap_log_error(APLOG_MARK, APLOG_DEBUG, APR_SUCCESS,
>> - r->server,
>> - "Adding CACHE_SAVE_SUBREQ filter for %s",
>> - r->uri);
>> -
>> ap_add_output_filter_handle(cache_save_subreq_filter_handle,
>> -NULL, r, r->connection);
>> +rv = ap_cache_try_lock(conf, r, NULL);
>
> Hm. If the resource was present in the cache and stale we already tried to
> acquire the
> lock in ap_cache_check_freshness. It seems wrong to try the lock twice.
There are two places where a lock is set. The first is when the entity
doesn't exist at all, and we only want to attempt to cache the entity
once. The second is when the entity goes stale, and we want to keep back
the thundering herd. This is why there are two instances of try_lock.
I found an issue with the second call, where if you already have a lock
the second attempt should succeed, fixed:
r808649.
>> @@ -368,7 +390,24 @@
>> ap_log_error(APLOG_MARK, APLOG_DEBUG, rv, r->server,
>> "cache: Cache provider's store_body failed!");
>> ap_remove_output_filter(f);
>> +
>> +/* give someone else the chance to cache the file */
>> +ap_cache_remove_lock(conf, r, cache->handle ?
>
> IMHO if cache->handle would be NULL we wouldn't be here, because we would
> back out
> before.
That makes one failure case work slightly differently to all the other
failure cases, it's far safer to just behave consistently across the board.
>> @@ -955,6 +1023,13 @@
>> /* array of identifiers that should not be used for key calculation */
>> ps->ignore_session_id = apr_array_make(p, 10, sizeof(char *));
>> ps->ignore_session_id_set = CACHE_IGNORE_SESSION_ID_UNSET;
>> +ps->lock = 0; /* thundering herd lock defaults to off */
>> +ps->lock_set = 0;
>
> Why don't you initialize lockmaxage_set and lockpath_set here as well.
Because it's unnecessary, the buffer is allocated with apr_pcalloc. None
of the _set's should be there, but one patch at a time. :)
> Overall the patch is hard to read since you are mixing typo fixes, style fixes
> and white space fixes with your functional changes. It would make it easier
> to read if you would separate these out in a separate patch.
That is Eclipse unfortunately, which takes it upon itself to strip
trailing whitespace on some lines without asking permission. Just went
through the initial patch, and didn't find any style fixes?
Regards,
Graham
--
smime.p7s
Description: S/MIME Cryptographic Signature
Re: four potential bugs discovered from CWRU research group
Following Nick's suggestions, I entered the bugs into Bugzilla. For the four bugs I discovered, three of them are duplicates of existing bugs, so I added comments and attached patches to the three bugs. I created a new bug 47753 for the only bug that is not similar to any existing bugs. The bugs can be found as follows: PR 47753: https://issues.apache.org/bugzilla/show_bug.cgi?id=47753 PR 31440: https://issues.apache.org/bugzilla/show_bug.cgi?id=31440 PR 38518: https://issues.apache.org/bugzilla/show_bug.cgi?id=39518 PR 39722: https://issues.apache.org/bugzilla/show_bug.cgi?id=39722 Any comment on these potential bugs is greately appreciated! Thanks very much! Boya On Wed, Aug 26, 2009 at 9:19 AM, Nick Kew wrote: > Boya Sun wrote: > >> Has anyone looked at these bugs yet? I would really appreciate it if >> someone can comment on the bugs. >> > > Have you entered them in Bugzilla at issues.apache.org? > They seem to reference existing bug reports there, > so a comment on those might be in order. > > What you posted to the list is rather hard to read, > because your mailer has formatted it as pseudo-HTML. > > -- > Nick Kew > -- BOYA SUN Computer Science Division Electrical Engineering & Computer Science Department 513 Olin Building Case Western Reserve University 10900 Euclid Avenue Cleveland, OH 44106 boya@case.edu
Re: svn commit: r808062 - /httpd/mod_ftp/trunk/README-FTP
Guenter Knauf wrote: > 2) If anyone would do so he would most likely be on Win32 where you get > a warning and you have to agree before an existing file is overwritten. I always click 'yes' without paying much attention :) Seriously ... > 3) If anyone would really want to combine into httpd sources then this > would certainly be a developer who is skilled enough to realize that the > root makefile is useless, and instead its required to modify httpd's > ./modules/NWGNUmakefile to include the ftp subdirectory + merge the > install part of mod_ftp's makefile into the httpd root NWGNUmakefile - > though I wonder who would do this all for zero benefit? My thought is a script in build/ which would inject NWGNUfoomakefile, Makefile-foo.win and Makefile-foo.in into the httpd build. Won't get to this instantly, but this layout makes things simpler. I have another makefile thought to pursue which should satisfy your goals more quickly, but let's drop this thread for the time being?
Re: Analysis of the Apache web server code repository
Ruediger Pluem wrote: >> I'm not sure I understand: you use the "Submitted by:" convention in the >> log message to list the contributors? Why? >> > Only if the committer is not the contributor. In this case we use this > convention > to document the provenance of the patch. > I see. I am glad to hear of different ways people use svn and believe that it would be reasonably simple to extend PanBI svn support to include this information. Not that anyone's asking :), but it's not likely that PanBI will incorporate such specific, per-project functionality: there are loads of reusable, generic functionality I have planned first... Cheers, Tomislav -- http://www.PanBI.org - business intelligence everywhere!
Re: svn commit: r808212 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_cache.xml modules/cache/cache_storage.c modules/cache/cache_util.c modules/cache/mod_cache.c modules/cache/mod_cache.h
On 08/27/2009 12:46 AM, minf...@apache.org wrote: > Author: minfrin > Date: Wed Aug 26 22:46:35 2009 > New Revision: 808212 > > URL: http://svn.apache.org/viewvc?rev=808212&view=rev > Log: > mod_cache: Introduce the thundering herd lock, a mechanism to keep > the flood of requests at bay that strike a backend webserver as > a cached entity goes stale. > > Modified: > httpd/httpd/trunk/CHANGES > httpd/httpd/trunk/docs/manual/mod/mod_cache.xml > httpd/httpd/trunk/modules/cache/cache_storage.c > httpd/httpd/trunk/modules/cache/cache_util.c > httpd/httpd/trunk/modules/cache/mod_cache.c > httpd/httpd/trunk/modules/cache/mod_cache.h Some new compiler warnings that result from the patch: mod_cache.c: In function 'cache_url_handler': mod_cache.c:114: warning: unused variable 'key' cache_util.c: In function 'ap_cache_try_lock': cache_util.c:243: warning: suggest parentheses around && within || cache_util.c: In function 'ap_cache_remove_lock': cache_util.c:307: warning: unused variable 'path' Regards Rüdiger
Re: Analysis of the Apache web server code repository
On 08/27/2009 09:20 PM, Tomislav Nakic-Alfirevic wrote: > William A. Rowe, Jr. wrote: > >> And also note, the meta log text line "Submitted by:" indicates that the >> committer is not the author - this is usually followed by one or more >> human names with an email name in <>'s. > > I'm not sure I understand: you use the "Submitted by:" convention in the > log message to list the contributors? Why? Only if the committer is not the contributor. In this case we use this convention to document the provenance of the patch. Regards Rüdiger
Re: Analysis of the Apache web server code repository
William A. Rowe, Jr. wrote: And also note, the meta log text line "Submitted by:" indicates that the committer is not the author - this is usually followed by one or more human names with an email name in <>'s. I'm not sure I understand: you use the "Submitted by:" convention in the log message to list the contributors? Why? Cheers, Tomislav
Re: svn commit: r808489 - /httpd/httpd/branches/2.2.x/docs/manual/mod/mod_proxy.xml
On 08/27/2009 06:18 PM, n...@apache.org wrote: > Author: niq > Date: Thu Aug 27 16:18:19 2009 > New Revision: 808489 > > URL: http://svn.apache.org/viewvc?rev=808489&view=rev > Log: > Improve docs note on PR 46665 (ProxyPassMatch buglet) as suggested by wrowe Don't you need to do these changes in the trunk doc as well to fix r808321? Regards Rüdiger
Re: svn commit: r808212 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_cache.xml modules/cache/cache_storage.c modules/cache/cache_util.c modules/cache/mod_cache.c modules/cache/mod_cache.h
On 08/27/2009 12:46 AM, minf...@apache.org wrote:
> Author: minfrin
> Date: Wed Aug 26 22:46:35 2009
> New Revision: 808212
>
> URL: http://svn.apache.org/viewvc?rev=808212&view=rev
> Log:
> mod_cache: Introduce the thundering herd lock, a mechanism to keep
> the flood of requests at bay that strike a backend webserver as
> a cached entity goes stale.
>
> Modified:
> httpd/httpd/trunk/CHANGES
> httpd/httpd/trunk/docs/manual/mod/mod_cache.xml
> httpd/httpd/trunk/modules/cache/cache_storage.c
> httpd/httpd/trunk/modules/cache/cache_util.c
> httpd/httpd/trunk/modules/cache/mod_cache.c
> httpd/httpd/trunk/modules/cache/mod_cache.h
>
> Modified: httpd/httpd/trunk/modules/cache/cache_util.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/cache/cache_util.c?rev=808212&r1=808211&r2=808212&view=diff
> ==
> --- httpd/httpd/trunk/modules/cache/cache_util.c (original)
> +++ httpd/httpd/trunk/modules/cache/cache_util.c Wed Aug 26 22:46:35 2009
> @@ -378,7 +546,64 @@
> return 1;/* Cache object is fresh (enough) */
> }
>
> -return 0;/* Cache object is stale */
> +/*
> + * At this point we are stale, but: if we are under load, we may let
> + * a significant number of stale requests through before the first
> + * stale request successfully revalidates itself, causing a sudden
> + * unexpected thundering herd which in turn brings angst and drama.
> + *
> + * So.
> + *
> + * We want the first stale request to go through as normal. But the
> + * second and subsequent request, we must pretend to be fresh until
> + * the first request comes back with either new content or confirmation
> + * that the stale content is still fresh.
> + *
> + * To achieve this, we create a very simple file based lock based on
> + * the key of the cached object. We attempt to open the lock file with
> + * exclusive write access. If we succeed, woohoo! we're first, and we
> + * follow the stale path to the backend server. If we fail, oh well,
> + * we follow the fresh path, and avoid being a thundering herd.
> + *
> + * The lock lives only as long as the stale request that went on ahead.
> + * If the request succeeds, the lock is deleted. If the request fails,
> + * the lock is deleted, and another request gets to make a new lock
> + * and try again.
> + *
> + * At any time, a request marked "no-cache" will force a refresh,
> + * ignoring the lock, ensuring an extended lockout is impossible.
> + *
> + * A lock that exceeds a maximum age will be deleted, and another
> + * request gets to make a new lock and try again.
> + */
> +status = ap_cache_try_lock(conf, r, (char *)h->cache_obj->key);
> +if (APR_SUCCESS == status) {
> +/* we obtained a lock, follow the stale path */
> +ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r->server,
> + "Cache lock obtained for stale cached URL, "
> + "revalidating entry: %s",
> + r->unparsed_uri);
> +return 0;
> +}
> +else if (APR_EEXIST == status) {
> +/* lock already exists, return stale data anyway, with a warning */
> +ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r->server,
> + "Cache already locked for stale cached URL, "
> + "pretend it is fresh: %s",
> + r->unparsed_uri);
> +apr_table_merge(h->resp_hdrs, "Warning",
> +"110 Response is stale");
The original code above uses some magic to avoid stomping on an already
existing Warning header:
/* make sure we don't stomp on a previous warning */
if ((warn_head == NULL) ||
((warn_head != NULL) && (ap_strstr_c(warn_head, "110") == NULL))
) {
apr_table_merge(h->resp_hdrs, "Warning",
"110 Response is stale");
Shouldn't we do the same thing here as well?
> +return 1;
> +}
> +else {
> +/* some other error occurred, just treat the object as stale */
> +ap_log_error(APLOG_MARK, APLOG_DEBUG, status, r->server,
> + "Attempt to obtain a cache lock for stale "
> + "cached URL failed, revalidating entry anyway: %s",
> + r->unparsed_uri);
> +return 0;
> +}
> +
> }
>
> /*
> Modified: httpd/httpd/trunk/modules/cache/mod_cache.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/cache/mod_cache.c?rev=808212&r1=808211&r2=808212&view=diff
> ==
> --- httpd/httpd/trunk/modules/cache/mod_cache.c (original)
> +++ httpd/httpd/trunk/modules/cache/mod_cache.c Wed Aug 26 22:46:35 2009
> @@ -111,41 +111,58 @@
> if (rv != OK) {
>
Re: svn commit: r808062 - /httpd/mod_ftp/trunk/README-FTP
Bill, William A. Rowe, Jr. schrieb: > Guenter Knauf wrote: >> what two different copies? where are these two? > > There were two flavors of the instructions for netware, one occurred > before and one after the section on rebuilding docs. whoups? >>> It is not clear ... gmake or make? make -f NWGNUftp-makefile will or >>> will not work properly? Netware eyeballs requested. >> GNU make, may it called gmake or make (but I think in main httpd docs we >> speak about gmake, so we should be consistent with this); > > +1, and from below, it looks like the right one is retained... will revise soon unless you beat me :) >> and no - '[g]make -f NWGNUftp-makefile' does NOT work due to our >> somewhat strange build system; therefore renaming to NWGNUmakefile IS >> mandatory, and brings up the Q again to rename it already in mod_ftp SVN >> as I did a while ago - but you were not fine with it because you thought >> it would break in-tree build, and I renamed back; but also pointed out >> that its NOT possible to do an in-tree build in such a simple way as >> just copying into the tree + there are no benefits to build in-tree >> because we anyway dont have the tools on Win32 (our build platform) to >> regenerate the docs properly so that the links to mod_ftp are worked in >> - or am I missing something here? > > Right, but anyone combining the packages into a single source would clobber Why would anyone do this? 1) I made clear *and* documented that this is *not* supported nor gives any benefit. 2) If anyone would do so he would most likely be on Win32 where you get a warning and you have to agree before an existing file is overwritten. 3) If anyone would really want to combine into httpd sources then this would certainly be a developer who is skilled enough to realize that the root makefile is useless, and instead its required to modify httpd's ./modules/NWGNUmakefile to include the ftp subdirectory + merge the install part of mod_ftp's makefile into the httpd root NWGNUmakefile - though I wonder who would do this all for zero benefit? > one or more of the NWGNUmakefile's that exist in the root; which is more > than likely the first, httpd's. So for safety's sake, I'm trying to be > consistent (and fix some win32 inconsistencies here, as well). I have no energy to further convince you, and dont care anymore about the naming of the root makefile; though it was crazy when two others who built mod_ftp in the past asked me: Q: why do we need to rename the makefile? A: because the httpd build system expects a NWGNUmakefile. Q: Why is it then not directly named NWGNUmakefile? A: Because it would clash with httpd's NWGNUmakefile when you copy everything over into httpd source tree in order to do in-tree build. Q: But the README states that in-tree is not supported nor of any benefit - so why should I try this at all? A: ??? /me not knowing what to answer :) > FWIW, if the top level makefile referred to itself as $(MAKEFILE), perhaps > this could be made to work in the future, having an arbitrary root makefile > name? Not that it's necessarily worth investing a lot of time in. The NetWare build system is not optimal, and neither Brad nor I developed it since we had no time these days - we had enough trouble with getting familar with the new compiler, and only used the GUI with project files; when Novell started to ship Apache 2.0 they needed to have a commandline build process which could be easily adapted for different build hosts and drive names, and so Novell India developed the build system. What I did in the past was fixing things as good as possible, but if I would have enough time I would really write something else from the scratch which looks more clear. However, if I would write something new from the scratch then I would probably consider going with OpenWatcom or gcc. Maybe we can look into a OpenWatcom build system for httpd HEAD - it could then build at least Win32 and NetWare targets, and probably also OS/2 (Brian?) ... Also would be a great thing if we could put the object files of each directory into a makefile.inc which could then be included from all platforms - this would simplify future changes a lot, and reduces maintainance. Günter.
Re: svn commit: r808062 - /httpd/mod_ftp/trunk/README-FTP
Guenter Knauf wrote: > what two different copies? where are these two? There were two flavors of the instructions for netware, one occurred before and one after the section on rebuilding docs. >> It is not clear ... gmake or make? make -f NWGNUftp-makefile will or >> will not work properly? Netware eyeballs requested. > GNU make, may it called gmake or make (but I think in main httpd docs we > speak about gmake, so we should be consistent with this); +1, and from below, it looks like the right one is retained... > and no - '[g]make -f NWGNUftp-makefile' does NOT work due to our > somewhat strange build system; therefore renaming to NWGNUmakefile IS > mandatory, and brings up the Q again to rename it already in mod_ftp SVN > as I did a while ago - but you were not fine with it because you thought > it would break in-tree build, and I renamed back; but also pointed out > that its NOT possible to do an in-tree build in such a simple way as > just copying into the tree + there are no benefits to build in-tree > because we anyway dont have the tools on Win32 (our build platform) to > regenerate the docs properly so that the links to mod_ftp are worked in > - or am I missing something here? Right, but anyone combining the packages into a single source would clobber one or more of the NWGNUmakefile's that exist in the root; which is more than likely the first, httpd's. So for safety's sake, I'm trying to be consistent (and fix some win32 inconsistencies here, as well). FWIW, if the top level makefile referred to itself as $(MAKEFILE), perhaps this could be made to work in the future, having an arbitrary root makefile name? Not that it's necessarily worth investing a lot of time in. At some point, an option to recombine top level win32+netware makefiles in the process of running ./buildconf would be cool, and I'm going to take a look at that, sometime. Not likely this week/month/year, though ;)
Re: svn commit: r808327 - /httpd/httpd/branches/2.2.x/docs/manual/mod/mod_proxy.xml
On 27 Aug 2009, at 16:37, William A. Rowe, Jr. wrote: +Note + The URL argument must be parsable as a URL before regexp + substitutions (as well as after). This limits the matches you can use. + See https://issues.apache.org/bugzilla/ show_bug.cgi">PR 46665 + for details and workaround ideas. This link looks no good. I'm also concerned about putting such links into bugzilla since it doesn't scale for our infrastructure. What about putting a couple of examples here, instead?. Heh. Well-spotted. So much for cut&paste. I'll give that some thought and update it. Unless you (or anyone) gets there first. -- Nick Kew
Re: svn commit: r808327 - /httpd/httpd/branches/2.2.x/docs/manual/mod/mod_proxy.xml
n...@apache.org wrote: > Author: niq > Date: Thu Aug 27 08:53:18 2009 > New Revision: 808327 > > URL: http://svn.apache.org/viewvc?rev=808327&view=rev > Log: > Document limitation to ProxyPassMatch in PR 46665 > > Modified: > httpd/httpd/branches/2.2.x/docs/manual/mod/mod_proxy.xml > > Modified: httpd/httpd/branches/2.2.x/docs/manual/mod/mod_proxy.xml > URL: > http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/docs/manual/mod/mod_proxy.xml?rev=808327&r1=808326&r2=808327&view=diff > == > --- httpd/httpd/branches/2.2.x/docs/manual/mod/mod_proxy.xml (original) > +++ httpd/httpd/branches/2.2.x/docs/manual/mod/mod_proxy.xml Thu Aug 27 > 08:53:18 2009 > @@ -944,6 +944,12 @@ > will cause a local request for > http://example.com/foo/bar.gif to be internally converted > into a proxy request to > http://backend.example.com/foo/bar.gif. > +Note > + The URL argument must be parsable as a URL before regexp > + substitutions (as well as after). This limits the matches you can use. > + See https://issues.apache.org/bugzilla/show_bug.cgi";>PR > 46665 > + for details and workaround ideas. This link looks no good. I'm also concerned about putting such links into bugzilla since it doesn't scale for our infrastructure. What about putting a couple of examples here, instead?.
Re: svn commit: r808062 - /httpd/mod_ftp/trunk/README-FTP
Bill, wr...@apache.org schrieb: > Author: wrowe > Date: Wed Aug 26 15:44:52 2009 > New Revision: 808062 > > URL: http://svn.apache.org/viewvc?rev=808062&view=rev > Log: > Attempt to merge two different copies of the netware build instructions. what two different copies? where are these two? > It is not clear ... gmake or make? make -f NWGNUftp-makefile will or > will not work properly? Netware eyeballs requested. GNU make, may it called gmake or make (but I think in main httpd docs we speak about gmake, so we should be consistent with this); and no - '[g]make -f NWGNUftp-makefile' does NOT work due to our somewhat strange build system; therefore renaming to NWGNUmakefile IS mandatory, and brings up the Q again to rename it already in mod_ftp SVN as I did a while ago - but you were not fine with it because you thought it would break in-tree build, and I renamed back; but also pointed out that its NOT possible to do an in-tree build in such a simple way as just copying into the tree + there are no benefits to build in-tree because we anyway dont have the tools on Win32 (our build platform) to regenerate the docs properly so that the links to mod_ftp are worked in - or am I missing something here? Günter.
Re: mod_cache, mod_deflate and Vary: User-Agent
On 8/26/09 3:20 PM, "Paul Querna" wrote: > I would write little lua scriptlets that map user agents to two > buckets: supports gzip, doesnt support gzip. store the thing in > mod_cache only twice, instead of once for every user agent. We do the same basic thing. We are moving towards the "if you say you support gzip, then you get gzip" attitude. I think less than 1% of our clients would be affected, and I think a lot of those are fake agents anyway. -- Brian Akins
Re: HTTP mode on Apache not working
Hi Madhuri, Please direct your question towards us...@httpd.apache.org, include more information than this too. Part of your config would be helpful. Kind regards ~Jorge On Thu, Aug 27, 2009 at 1:11 PM, Madhuri wrote: > > Hi All - This is the first time I am setting up apache server. It works fine > on SSL mode with https://XX/, however it does not work with > http://XX/. Will really appreciate any help. > > Thanks > Madhuri > -- > View this message in context: > http://www.nabble.com/HTTP-mode-on-Apache-not-working-tp25167526p25167526.html > Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com. > >
HTTP mode on Apache not working
Hi All - This is the first time I am setting up apache server. It works fine on SSL mode with https://XX/, however it does not work with http://XX/. Will really appreciate any help. Thanks Madhuri -- View this message in context: http://www.nabble.com/HTTP-mode-on-Apache-not-working-tp25167526p25167526.html Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.
Re: mod_cache, mod_deflate and Vary: User-Agent
> William A. Rowe, Jr. > > I think we blew it :) > > Vary: user-agent is not practical for correcting errant browser behavior. You have not 'blown it'. >From a certain perspective, it's the only reasonable thing to do. Everyone keeps forgetting one very important aspect of this issue and that is the fact that the 'Browsers' themselves are participating in the whole 'caching' scheme and that they are the source of the actual requests, so their behavior is as much a part of the equation as any inline proxy cache. There is no real solution to this problem. The HTTP protocol itself does not have the capability to deal with things correctly with regards to compressed variants. The only decision that anyone needs to make is 'Where is the pain factor?'. If you VARY on ANYTHING other than 'User-Agent' then this might show some reduction of the pain factor at the proxy level but you have now exponentially increased the pain factor at the infamous 'Last Mile'. Most modern browsers will NOT 'cache' anything that has a 'Vary:' header OTHER than 'User-Agent:'. This is as true today as it was 10 years ago. The following discussion involving myself and some of the authors of the SQUID Proxy caching Server took place just short of SEVEN (7) YEARS ago but, as unbelievable as it might seem, is still just as relevant ( and unresolved )... http://marc.info/?l=apache-modgzip&m=103958533520502&w=2 It's way too long to reproduce here but here is just the SUMMARY part. You would have to access the link above to read all the gory details... [snip] > Hello all. > > This is a continuation of the thread entitled... > > [Mod_gzip] "mod_gzip_send_vary=Yes" disables caching on IE > > After several hours spent doing my own testing with MSIE and > digging into MSIE internals with a kernel debugger I think I > have the answers. > > The news is NOT GOOD. > > I will start with a SUMMARY first for those who don't have the > time to read the whole, ugly story but for those who want to > know where the following 'conclusions' are coming from I > refer you to the rest of the message and the "detail". > > SUMMARY > > There is only 1 request header value that you can use with > "Vary:" that will cause MSIE to cache a non-compressed > response and that is ( drum roll please ) "User-Agent". > > If you use ANY other (legal) request header field name in > a "Vary:" header then MSIE ( Versions 4, 5 and 6 ) will > REFUSE to cache that response in the MSIE local cache. > > This is why Jordan is seeing a caching problem and Slava > is not. Slava is 'accidentally' using the only possible "Vary:" > field name that will cause MSIE to behave as it should > and cache a non-compressed response. > > Jordan is seeing non-compressed responses never being > cached by MSIE because the responses are arriving > with something other than "Vary: User-Agent" like > "Vary: Accept-Encoding". > > It should be perfectly legal and fine to send "Vary: Accept-Encoding" > on a non-compressed response that can 'Vary' on that field > value and that response SHOULD be 'cached' by MSIE... > but so much for assumptions. MSIE will NOT cache this response. > > MSIE will treat ANY field name other than "User-Agent" > as if "Vary: *" ( Vary + STAR ) was used and it will > NOT cache the non-compressed response. > > The reason the COMPRESSED responses are, in fact, > always getting cached no matter what "Vary:" field name > is present is just as I suspected... it is because MSIE > decides it MUST cache responses that arrive with > "Content-Encoding: gzip" because it MUST have a > disk ( cache ) file to work with in order to do the > decompression. > > The problem exists in ALL versions of MSIE but it's > even WORSE for any version earlier than 5.0. MSIE 4.x > will not even cache responses with "Vary: User-Agent". > > That's it for the SUMMARY. > > The rest of this message contains the gory details. [/snip] I participated in another lengthy 'offline' discussion about all this some 3 or 4 years ago again with the authors of SQUID. There was still no real resolution to the problem. The general consensus was that if there is always going to be a 'pain factor' then it's better to follow one of the rules of Networking and assume the following... "The least amount of resources will always be present the closer you get to the last mile." In other words... it's BETTER to live with some redundant traffic at the proxy level, where the equipment and bandwidth is usually more robust and closer to the backbone, than to put the pain factor onto the 'last mile' where resources are usually more constrained. If anyone is going to start dropping some special code anywhere to 'invisibly handle the problem' my suggestion would be to look at coming up with a scheme that undoes the damage these out-of-control redundant 'User-Agent' strings are causing. The only thing a proxy cache really needs to know is whether a certain 'User-Agent' string represents a different level of DEVCAP th
