Pages for all users - authenticated and anonymous see gibberish on the page. Once refreshed the page shows normal content.
The errors I get are

Warning: Cannot modify header information - headers already sent in drupal_serve_page_from_cache() (line 1348 of ..\www\includes\bootstrap.inc).
Warning: ini_set() [ref.outcontrol]: Cannot change zlib.output_compression - headers already sent in drupal_serve_page_from_cache() (line 1353 of ..\www\includes\bootstrap.inc).

Info from my settings -

/**
* Authcache Module settings
*/
$conf['cache_inc'] = './sites/all/modules/authcache/authcache.inc';
/**
* Add APC Caching.
*/
$conf['cache_backends'] = array('sites/all/modules/apc/drupal_apc_cache.inc');
$conf['cache_class_cache'] = 'DrupalAPCCache';
$conf['cache_class_cache_bootstrap'] = 'DrupalAPCCache';
//$conf['apc_show_debug'] = TRUE;  // Remove the slashes to use debug mode.
/**
* Add Memcache Caching.
*/
  $conf['cache_backends'][] = 'sites/all/modules/memcache/memcache.inc';
  $conf['cache_default_class'] = 'MemCacheDrupal';
  $conf['memcache_key_prefix'] = 'qwikerliquor';
  $conf['memcache_servers'] = array(
        '127.0.0.1:11211' => 'default',
        '127.0.0.1:11212' => 'page'
    );
  $conf['memcache_bins'] = array(
        'cache' => 'default',
        'cache_page' => 'page'
    );
/**
* Settings for Secure Pages module
*/
$conf['https'] = TRUE;

To summarize, authcahe can't be used due to this issue. No changes were made to default settings other than selecting authenticated user list, Don't cache Drupal Ajax requests and Only cache HTTP 200 OK pages (exclude 404, 403, etc) settings.

Anyone having this issue?

Files: 
CommentFileSizeAuthor
#4 html anonymous user.png86.8 KBanik8z
authcache.png104.23 KBanik8z

Comments

Having this issue today as well. I only have this problem however with the roles for which caching is not enabled. I had all checkboxes enabled except for Anonymous users, giving me problems with this role. Enabling caching for the Anonymous role fixed this problem for me.

Usable work-around for now but still a pretty nasty issue.

I was bit surprised it had not been reported earlier and was wondering if it was maybe due to some combination of caching modules settings I have created. Question for you - how long have you been using the module for and if there have been others with this problem and how they resolved it.. I am using Boost so your workaround will not have an effect for Anonymous users settings. Will test it and report back..

This problem is related to page compression and most probably is a combination of several issues.

Short answer: Please try to disable page compression using the following line of code in your settings.php file:

<?php
$conf
['page_compression'] = false;
?>

Long answer: Web applications use HTTP headers to communicate some properties about the content delivered to the browser. For example when Drupal serves compressed content, the header Content-Encoding:gzip is set. The browser then knows that it needs to decompress the content prior to rendering. If this header is missing, the browser will just try to render the gzip-stream, resulting in the gibberish you see instead of a page.

The challenge is now to identify the piece of code which is triggering that the headers are sent prematurely. In order to do this please try the following steps first:

  1. Disable page_compression
  2. Clear the cache
  3. Navigate to a cachable page and inspect its source code

Do you see any content / error message before the HTML actually starts?

StatusFileSize
new86.8 KB

I am attaching the screenshot for anonymous user. There is no readable html before the characters begin. Without selecting authcache for anon users - For admin user the content displays as normal and at the bottom the characters begin.
With selecting authcache for anon users - The admin pages display as normal.

For non admin authenticated users I could not test because I don't get a login screen.

I think this error is related to the way Admin_menu caches itself in the browser.

Suggested work around is here http://drupal.org/node/1754180#comment-6412092

@anik8z: Would you please test again with the newly released version 7.x-1.3?

Priority:Major» Normal
Status:Active» Postponed (maintainer needs more info)

I can confirm that this issue was resolved for me after updating to 7.x-1.3

Spoke too soon. After clearing caches and invalidating user sessions in the authcache config page this issue is back.

@ericmulder1980: Can you give me an URL (via PM)?

My apologies for not responding sooner. Since there is a significant per user dynamic content I decided to not use Authcache and deal with complexities of Ajax refesh etc

Component:Code» Documentation
Status:Postponed (maintainer needs more info)» Needs review

I just found the cause for this issue. I cannot think of an easy way to implement a solution directly into authcache. Therefore I'll add the following section to the readme file:

4. Remove variables affecting the page cache from the database
   Authcache intercepts the drupal bootstrap process in a very early stage,
   when configuration settings are not yet loaded from the database. Therefore
   when a page is served from the cache the default settings will be used.
   However it is very important that the settings affecting the page cache are
   the same when a page is saved to the cache as well as when it is served
   from the cache. Therefore please remove the following variables from the
   database either using "drush vdel variable-name" or using the variable
   editor included in the devel module.
   1. page_compression
      Defaults to true. If it is set to false in the database, browsers will
      not be able to decode the cached responses and in many cases will
      display gibberish.
   2. page_cache_maximum_age
      Defaults to 0.
   If you want to customize one of these values, you need to do that by
   specifying it in settings.php. For example when intermediary caches and the
   users browser should be allowed to keep cached copies for 5 minutes then
   add the following line to your settings.php:
   $conf['page_cache_maximum_age'] = 300

Ok, I made up my mind and I committed a different solution now which actually is very much what Drupal core does to work around this problem.

The new solution is actually more robust, so new users will have an easier time to get started with authcache. However it also puts a little burden onto those users who need to squeeze every millisecond out of the page-serving process. Those who use a cache-class from contrib (e.g. memcache) now need explicitly tell authcache to avoid the database when serving pages from the cache via settings.php:

<?php
$conf
['page_cache_without_database'] = TRUE;
?>

Related issue: #1826284: Variables are not loaded yet causing some functionality to fail.

Status:Needs review» Fixed

Status:Fixed» Closed (fixed)

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