hello

i'm having some issues with Display page timer enabled on Devel, while Page Compression is enabled in Drupal, when using the Cache Backport module (backport of D7 cache.inc), for anonymous sessions, with access devel information permission.

the issue was started here

getting some unrecognizable output, randomly & occasionally, when viewing nodes (cache_page).
it seems to be Gzip content, with improperly set headers or content type.
this could be a problem in cache backport or on the memcache module

Cache Backport 1.0-alpha3
Memcache API 1.0-beta3
CSS Gzip 1.3
JavaScript Aggregator 1.5
Drupal Cache, Block Cache, Page Compression, CSS & Javascript aggregation and compression/minify.

and was isolated on comment 20:

requirements:
* Drupal 6.20
* Cache Backport 6.x-1.0-alpha3/4
* a cache engine (APC 7.x-1.0-beta2, Memcache API 7.x-1.0-beta3, File Cache 7.x-1.0-alpha2, or supplied DB)
* Devel 6.x-1.23
* Page Compression enabled in Drupal
* Display page timer enabled in Devel
* Access devel information permission enabled for anonymous user
* Navigate site randomly with a anonymous session

//edit:
just noticed that with this config, Devel won't show anything on the footer for the anonymous session.
and the information won't update ever for the anonymous session. you need to clear the caches all the time.
Devel for Drupal 7 probably has this changed and fixed to accommodate the new cache.inc.

i use Access devel information permission enabled for anonymous user when testing performance.
it should only be used in development.

the problem seems to revolve with Response Headers, with might not be properly dealt with in Devel 6.x, but likely is fixed on Devel 7.x. requesting a fix / partial backport of Devel 7.x

Comments

pounard’s picture

Sub.

salvis’s picture

I don't quite understand what this is all about, but if you say that the Devel data is not updated for the anonymous user until you clear the cache, then that's exactly what the cache is supposed to do: save the rendered page and serve it from the cache, until some action on the site invalidates the cache.

pounard’s picture

The problem he encountered can point to an underlaying different problem. What's happening here is that when the page timer is enabled and the page is served from cache, Devel sometime messes up with the final rendering. It does not happen all the time, but it seems linked to that page timer.

The problem manifests itself by making the client showing gzip garbage content instead of ungziping the content, and it might be due to the fact that Devel adds information into the page footer which is arbitrary printed during at footer time instead of being gzipped with the content (when reaching the page footer, content has already been gziped).

This is just an asumption, but in Devel 6.x-1.23 there is actually a comment saying (devel.module, in devel_shutdown_real() line 865):

// TODO: gzip this text if we are sending a gzip page. see drupal_page_header().

It might be related.

Even if our bug here is really random and only here in really rare case, it could worth the shot to find out why and fix this because it could happen in other use cases.

lpalgarvio’s picture

pounard explains it well.

AFAIK, this issue also occurs when using Memcache API, but not when using Cache Router.

manasiv’s picture

Were you able to check if this is a memcache issue? I am using memcache on drupal 6.20 and the logs show random access denied errors for authenticated users. I am using memcache 6.x-1.10

vegardx’s picture

I haven't fully verified it yet, but seems like this is an issue in Drupal 7 too. If you're gzipping the content it seems like Devel adds some data even after it has been gzipped, making things like Varnish blow up because it can't make sense of the data. A quick and easy way around the issue is to disable gzipping in Drupal and instead do it in Varnish.

   11 ObjHeader    c Content-Encoding: gzip
   11 FetchError   c Junk after gzip data
   11 Gzip         c u F - 6793 31170 80 80 54275
   11 VCL_call     c error deliver
   11 VCL_call     c deliver deliver
   11 TxProtocol   c HTTP/1.1
   11 TxStatus     c 503
   11 TxResponse   c Service Unavailable
willzyx’s picture

Status: Active » Closed (outdated)

Closed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.