You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2007/11/12 00:39:12 UTC
DO NOT REPLY [Bug 43838] New: - If-Modified-Since request and htcacheclean conflict
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43838>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43838
Summary: If-Modified-Since request and htcacheclean conflict
Product: Apache httpd-2
Version: 2.2.3
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: mod_cache
AssignedTo: bugs@httpd.apache.org
ReportedBy: alec@bdt.co.nz
Setup:
Apache2.2.3 setup as a reverse proxy, in a test environment ready to replace
a production box.
Problem:
Excessive 'If-Modified-Since' traffic to upstream server.
Cause:
Every night htcacheclean is run.
A returning Client requests an object/file using 'If-Modifed-Since' in the
header, as the client has locally cached copy.
Symptom:
Reverse proxy makes 'If-Modifed-Since' request to upstream server as object
is not available in cache. Upstream server will reply with '304 Not-Modifed'.
Note, Proxy still doesn't have a copy.
The expected action would be for the proxy to get the object, and
report '304 Not-Modifed' to the client, so that the next request is served out
of cache, and no further traffic occurs between proxy and upstream server.
Observation:
If the clients cache is cleared, the next request comes from the upstream
server, then subsequent requests come from the proxy's cache.
Hack:
In mod-proxy-http.c we have removed the test 'if r->main' check (snippet
below), which appears to remove the "If-*" headers to the upstream server, but
this may have other side effects, but gives us the desired operation.
/* for sub-requests, ignore freshness/expiry headers */
// CJW - Ignore Freshness on requests
//if (r->main) {
if ( !strcasecmp(headers_in[counter].key, "If-Match")
|| !strcasecmp(headers_in[counter].key, "If-Modified-Since")
|| !strcasecmp(headers_in[counter].key, "If-Range")
|| !strcasecmp(headers_in[counter].key, "If-Unmodified-Since")
|| !strcasecmp(headers_in[counter].key, "If-None-Match")) {
continue;
}
//}
How should this senario really be fixed?
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 43838] - If-Modified-Since request and htcacheclean conflict
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43838>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43838
fielding@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
Component|mod_cache |mod_proxy
------- Additional Comments From fielding@apache.org 2007-12-28 18:22 -------
The right fix is a configuration directive that tells us the
proxy is supposed to remove conditionals on a GET when
the response is not already in the cache. Not all sites are
concerned about reducing the number of 304 responses from the
backend. For example, your solution will mean that anything
that mod_cache has decided not to cache for other reasons, such
as being a low hit potential or simply too big, will result
in repeated full transfers from the backend instead of 304s.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 43838] - If-Modified-Since request and htcacheclean conflict
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43838>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43838
------- Additional Comments From alec@bdt.co.nz 2008-01-28 17:24 -------
Referring to http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
section 10.3.5 304 Not Modified
"If a 304 response indicates an entity not currently cached, then the cache
MUST disregard the response and repeat the request without the conditional"
Reading the RFC, suggests that no matter what, if the image isn't in cache it
should be requested.
Our deployment is an offsite image-cache, with 1Gb connection to internet.
With our hack, I tend to agree with the concerns of large files (wheter
modified or not) being repeatedly requested from the backend should the cache
server decide not to cache it due to CacheMaxFileSize or some other reason.
The sites that are reverse proxied don't have large image files and represent
~95% of our traffic, the other remaining sites that may have large images are
not proxied - the traffic goes over our 10Mb link, versus 1Gb at ISP.
In general, the hack works for us, but don't want to be maintaining the code
on an on going basis.
Is there any work being done on this?
Thanks Alec
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org