Download & Extend

Try to request .html instead somepage.html

Project:Boost
Version:4.7.x-1.x-dev
Component:Apache integration
Category:bug report
Priority:normal
Assigned:Arto
Status:closed (fixed)

Issue Summary

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} !^/$

AttachmentSize
dothtml.patch.txt402 bytes

Comments

#1

I had the same problem - thanks for the fix!

#2

Just 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

#3

By 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

#4

I had the same issues and pasting it further towards the end of the boost entries in .htaccess seems to have done the magic.

#5

One 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

#6

Assigned to:Anonymous» Arto

#7

This 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)

#8

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?

I have same problem and added next strings to .htaccess (same headers Drupal core sends, but when we missed Drupal these headers missed too):

  Header add Expires "Sun, 19 Nov 1978 05:00:00 GMT"
  Header add Cache-Control "no-store, no-cache, must-revalidate, post-check=0, pre-check=0"

I think it must help, though not sure yet.

#9

Status:needs review» active

Arto - I've recently switched hosts and I'm running into the same problem as "http://drupal.org/node/103884#comment-189536":

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?

Axel's suggestion on "http://drupal.org/node/103884#comment-225590" doesn't seem to solve it.

Any ideas?

#10

Status:active» fixed

These 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.

#11

Status:fixed» closed (fixed)

#12

i 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

#13

Brush, there's not a whole lot that can be done about it unless you give enough details that the problem can be reproduced.