Re: mod_cache deliver 304 instead of (not so) stale cache entries
[EMAIL PROTECTED] wrote: Sander Striker wrote: [EMAIL PROTECTED] wrote: [...] Might as well not do revalidation in that case; actually that would be better, because the 304's that are returned may not even be correct. The conditions are replaced with the ones from the cache, remember? Yes, I remember, but I must admit that I am slightly confused now. When should we avoid revalidation with the conditionals from the cache? Well, we shouldn't; it's a workaround for a different bug. The workaround however would be to _never_ use the conditionals from the cache. If the original request does not contain any conditionals? This is what my patch does What I am trying to point out is that you can't use the conditionals from the cache at all if the CACHE_SAVE filter isn't being invoked. You will get a 304 based on the conditionals from the cache, which may not be correct with respect to the conditionals from the request. [..cut..] I can see the application. Are you up for submitting a patch to the default handler? :) I have attached a patch for this. Two comments: 1. I am not very familar with buckets and brigades, so please check closely if I did it correct (my tests make me think so). If I did something wrong feedback is appreciated such that I can do it better next time :-) 2. ap_meets_conditions returns 3 different values: OK, HTTP_PRECONDITION_FAILED and HTTP_NOT_MODIFIED. In my patch I assume that in all cases the response should go down the filter chain. I'll review your patch. I'll massage it into shape if needed, given your comments. Thanks, Sander
endless loop trying to create ssl_scache (2.0.54)
Hi, I had just killed off my apache2 and tried to restart it when the following kept apache running at ~100% cpu usage, trying to create the file but failing. Attaching a strace resulted in an endless loop of: stat64(/var/run/apache2/ssl_scache, 0xb8a0) = -1 ENOENT (No such file or directory) open(/var/run/apache2/__db.ssl_scache, O_RDWR|O_CREAT|O_EXCL| O_LARGEFILE, 0644) = -1 EEXIST (File exists) open(/var/run/apache2/__db.ssl_scache, O_RDWR|O_CREAT|O_EXCL| O_LARGEFILE, 0644) = -1 EEXIST (File exists) open(/var/run/apache2/__db.ssl_scache, O_RDWR|O_CREAT|O_EXCL| O_LARGEFILE, 0644) = -1 EEXIST (File exists) Removing the files from /var/run/apache2/ resolved the issue and apache is happily serving again :) Could it be a locking issue? (O_EXCL) IMHO it should simply abort after trying the above for n (say 50?) times and at least log it then. Greets, Jeroen -- related version info: ii apache2-common 2.0.54-4next generation, scalable, extendable web server ii apache2-mpm-prefork 2.0.54-4traditional model for Apache2 ii apache2-utils 2.0.54-4utility programs for webservers ii libapache2-mod-php4 4.3.10-15 server-side, HTML-embedded scripting language (apache 2.0 module) signature.asc Description: This is a digitally signed message part
adddefaultcharset and proxypass
Hi All, apache_2.0.52 - In an instance of a webserver, AddDefaultCharset is set to iso-8859-1, and a subset of the website is ProxyPass'ed to another site, which does not have AddDefaultCharset set. The front-end server adds charset=iso-8859-1 to the header of the output of the backend server. Is this expected behaviour? Thanks, Jie
Re: adddefaultcharset and proxypass
Jie Gao wrote: Hi All, apache_2.0.52 - In an instance of a webserver, AddDefaultCharset is set to iso-8859-1, and a subset of the website is ProxyPass'ed to another site, which does not have AddDefaultCharset set. The front-end server adds charset=iso-8859-1 to the header of the output of the backend server. Is this expected behaviour? Expected Behavior: yes. Desired: Depends. If you don't want it, or if it is causing problems, feel free to turn it off. Anyways, in newer versions, we do not include the AddDefaultCharset in the configuration. -Paul
