Hi,

Before boost was enabled, users that have persistent login turned on, don't need to log in again when revisiting the site (without logging out).

Now users need to login again and it seems persistent login is not working anymore.

My current setup is:
Boost 6.x-1.13
Drupal 6.14
Apache 2.0
PHP 5.2.6
Mysql 5.0

Thanks.

CommentFileSizeAuthor
#7 boost-617886.patch1.7 KBmikeytown2
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mikeytown2’s picture

Hmmm, I haven't experienced this my self. How long is the persistent login set for? Using core (default 2 weeks?) or another module to do this? Any other tips you can provide me for replicating this bug?

The one thing that comes to mind is ETags,
http://drupal.org/node/545908#rules
Set it to None, save, & then copy the new rules over the old rules in your htaccess file.

If you know how to look at headers, check for etags before doing this. Let me know if this setting removes the etag, It's a fairly new setting so verification by multiple people is always nice.

h3000’s picture

Status: Active » Fixed

Hi mikeytown2,

The Etag setting was set to "Set FileETag 'None' - Do not send an etag".

I tried changing the setting to "Do Nothing" and it now works.

Thanks!

BlueIrisNina’s picture

Hi mikeytown2,

I had the Etags set to none and it wasn't working (I checked .htaccess on the server and it was in the file). I moved it outside of the Boost code and now it works.

Nina

mikeytown2’s picture

Title: Persistent Login not working when Boost is enabled » ETag Location
Component: Cookie issues » Apache integration
Priority: Critical » Normal
Status: Fixed » Active

Would you mind testing the location of the etag for me?
Try it at the top of the rules

### BOOST START ###
  AddDefaultCharset utf-8
  FileETag None
  <FilesMatch "(\.html|\.html\.gz)$">
...

Try it at the bottom

  FileETag None
  ### BOOST END ###

Try it by breaking out and back in of the mod_rewrite section

</IfModule>
FileETag None
<IfModule mod_rewrite.c>
  RewriteEngine on
  ### BOOST END ###
BlueIrisNina’s picture

Hi,

I am having a little trouble figuring out if everything is getting cleared but here's what I got for results and what I did to clear.

Where it was before I tested (by itself above the Boost code) I got a 'D' -as opposed to an 'F' when I had it in there through Boost - when I ran YSlow. The three things it didn't pick up and still had misconfigured tags was my favicon and my aggregated .js and .css files.

When I moved it to top of Boost rules I got a 'B' with only the favicon coming up as misconfigured. Before testing this I flushed the caches, cleared the Boost cache page and ran cron (this must clear it all out, right? : )

I then moved it to the bottom, ran cron and flushed and again a 'B'.

I then broke it out with your code in the rewrite section and again 'flushed and ran' and again a 'B'.

I am having the problem as the other person in this thread with this flushing while updating... I have found that if I am working on my style sheets and Boost is on I need to "un-aggregate them" and still flush and sometimes run (cron) to see the updates.

Is there an easier way?

Nice module BTW. Really helped me out with the speed. This is my first Drupal site. It's still running a bit slow (3.02 secs on the home page) but far, far better than it was. YSlow indicates I should have some far future expiring headers. I noticed in the Boost code there is something about expires and it's set at 1978 and another setting I believe looks like 2 weeks out. Is there something I should do to far expire my jpgs and gifs?

Sorry if I sound inept - this is all new stuff to me...

Thanks,
Nina

mikeytown2’s picture

With the original placement of the Etags by this module you where having issues with logged in users being logged out correct?

Here's a post that deals with long cache times for other objects; may not be 100%, its a little old... things change fairly quickly around here.
http://drupal.org/node/185075#comment-1560198

Also be aware that ETags are not "Evil" like yslow would make you believe. If I can set an Etag for just the boosted cache, some very good things happen in terms of reducing the load on your server. Server will send out a 304 instead of the file saving you bandwidth. Only when that file has changed (browser & server know due to the etag) will the new file be sent out. This is a nice side effect of the static cache; ETags are useful for webpages. The yslow rule in regards to ETags is mainly for server clusters. Either way try it with this setting in boost Set FileETag 'MTime Size' - Useful in server clusters as this is the correct way to do ETags in a cluster, and it might make YSlow be quiet on the subject.

Example code placement for correct ETags

### BOOST START ###
  AddDefaultCharset utf-8
  FileETag MTime Size
  <FilesMatch "(\.html|\.html\.gz)$">
...

If you could test this, I would appreciate it.

mikeytown2’s picture

Status: Active » Needs review
FileSize
1.7 KB

Patch for moving the etag to the top position.

mikeytown2’s picture

Status: Needs review » Fixed

committed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.