Closed (fixed)
Project:
Boost
Version:
4.7.x-1.x-dev
Component:
Apache integration
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
17 Dec 2006 at 23:42 UTC
Updated:
3 Sep 2007 at 12:50 UTC
Once time I got 'Access forbidden!' on idex page and in Apache error log was:
client denied by server configuration: /[skiped]/cache/www.roleplay.ru/0/.html
As you see not existent '.html' page was requested instead of real page. Other pages successfully loaded from cache at this time. I got this error on two sites. I don't know cause of this error - is this Apache settings or is this a Boost problem? But for prevent it in future I applied next workaround: add new rule to .htaccess:
RewriteCond %{REQUEST_URI} !^/$
| Comment | File | Size | Author |
|---|---|---|---|
| dothtml.patch.txt | 402 bytes | axel |
Comments
Comment #1
lennart commentedI had the same problem - thanks for the fix!
Comment #2
drhilarius commentedJust for info for the developers, I also had this problem after about 2 weeks of using boost. I'm not sure what caused it. Let me know if I can help to track it down.
rich
Comment #3
drhilarius commentedBy the way that .htaccess file change didn't work for me... is there anything special I need to do, like dumping all the cache files or something?
I've turned off boost until this gets ironed out... please let me know if I can be of diagnostic help.
thanks,
rich
Comment #4
challer commentedI had the same issues and pasting it further towards the end of the boost entries in .htaccess seems to have done the magic.
Comment #5
challer commentedOne problem that I still have seems to be a browser caching one, but I stil wonder if there's a way around. Logged-in users that signed in on the frontpage get kicked out once they go back to the frontpage. Seems like there's still a cached version stored locally that comes up again. A hard refresh solves the problem, but most of them don't know. Any thoughts how to avoid that? Thanks
Comment #6
Arto commentedComment #7
fiLi commentedThis patch works great. I've had the same problem described here, and I applied the simple fix, and it's been working wonderfully ever since. I suggest that this would be added to the main code, it is vital.
(BTW - Looking forward to seeing this for Drupal 5.X)
Comment #8
axel commentedI have same problem and added next strings to .htaccess (same headers Drupal core sends, but when we missed Drupal these headers missed too):
I think it must help, though not sure yet.
Comment #9
fiLi commentedArto - I've recently switched hosts and I'm running into the same problem as "http://drupal.org/node/103884#comment-189536":
Axel's suggestion on "http://drupal.org/node/103884#comment-225590" doesn't seem to solve it.
Any ideas?
Comment #10
Arto commentedThese issues should be fixed in the latest development snapshot (both for 4.7 and 5.x). Please upgrade to that (the updated release files will be available later today once the packaging script has run) and report back if you have any further trouble.
Comment #11
(not verified) commentedComment #12
brush@groups.drupal.org commentedi continue to experience this issue, regularly. am trying various workarounds, but would like to have the front page properly cached at least most of the time.
.b
Comment #13
Arto commentedBrush, there's not a whole lot that can be done about it unless you give enough details that the problem can be reproduced.