I've serious problem with my Drupal websites.
It a not first time and not only related to one page and it happen after some unknown time.
Whole page looks like compressed instead of proper html.
Check in attachment.
Any ideas what's going on?
I've tried to disable some Compresing options in Settings, but I'm not sure if it's related to Drupal. Probably it's, because even I've tried refresh many time the same page, problem is the same. When I'm clearing Drupal cache, everything is backing to normal.

CommentFileSizeAuthor
#11 Clipboard01.jpg78.15 KBkenorb
Clipboard01.jpg371.48 KBkenorb

Comments

blakehall’s picture

Category: bug » support
Status: Active » Postponed (maintainer needs more info)

Is caching disabled? You can turn it off at admin/settings/performance.

Looks to me like a problem with your PHP / Apache configuration rather than drupal...

Mike_Waters’s picture

Is it possible that you are sending compressed (gzip) content without the proper headers (Content-type)? I've had buggy modules mess with what's sent to the browser.
The first thing I would do (absent firebug or fiddler) is turn off caching and compression in your drupal performance settings, and comment out anything related to mod_deflate in your .htaccess file (anything between and ). If it's still a problem, it's probably not compression.

If you feel that you are proficient enough, I would download the Fiddler HTTP analyzer, enable it in your browser settings (proxy), and check out what the server is actually sending to you.
Fiddler: http://www.fiddlertool.com/fiddler/

kenorb’s picture

Thanks for advice.

I haven't change .htaccess and I'd this problem only on two websites.
Maybe it's a problem with some buggy modules.

On one website I'm using following modules:
autoassignrole auto_nodetitle cck click firestats google_analytics graphstat mimemail modr8 nodefamily nodeprofile nodewords nodewords_bypath nodewords_nodetype panels pathauto send signup simplenews simplenews_digest simplenews_register simplenews_roles simplenews_scheduler spam subform_element tinymce title_rewrite token troll user_register_notify user_stats views visibility_api wordfilter xmlsitemap xstatistics

on second where was similar problem:
advanced_help auto_nodetitle calendar cck date email filefield formblock graphstat image img_assist jstools mimemail nodewords PalmHotelUk rules search404 site_map tinymce token views workflow

Modules in which I found call to header() function:
xmlsitemap troll spam graphstat views calendar img_assist

I'll try to reproduce it again.

kenorb’s picture

I've got following error:

<br />
<b>Warning</b>:  gzinflate(): data error in <b>/home/palmuk/public_html/includes/bootstrap.inc</b> on line <b>636</b><br />

when I'm testing using JMeter

GET http://www.palmhoteluk.com/

[no cookies]

Request Headers:
Connection: keep-alive

Maybe that's the reason, Drupal trying to send compressed page even browser doesn't support it?

Mike_Waters’s picture

Well, that line on bootstrap.inc is only evaluated if page_compression (Drupal's, a-la Settings->Performance) is enabled and the browser does not support gzip encoding:

  if (variable_get('page_compression', TRUE)) {
    // Determine if the browser accepts gzipped data.
    if (@strpos($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip') === FALSE && function_exists('gzencode')) {
      // Strip the gzip header and run uncompress.
      $cache->data = gzinflate(substr(substr($cache->data, 10), 0, -8));  //<-- line 636
    }
    elseif (function_exists('gzencode')) {
      header('Content-Encoding: gzip');
    }
  }

It may be that the cached data is not actually gzip encoded in the first place (even though page_compression is on), and so the call to gzinflate causes an error. Are you using any third-party caching tools (like apc or xcache)?

Are you using mod_deflate in combination with Drupal's page compression? (Acc. to the documentation, "By default, Drupal compresses the pages it caches in order to save bandwidth and improve download times. This option should be disabled when using a webserver that performs compression.")

Is there any other reason why Drupal's cache would contain plain text even though page_compression is on?

kenorb’s picture

I'm not using any cache engine.
Maybe the problem is that Drupal trying to uncompress non-compressed website, because it only rely on variable, which can be change in any moment, but after that compressed pages are still in the cache. I think each cached page should be checked separately if it's compressed or not.

Mike_Waters’s picture

That sounds likely. Does this problem clear up if you turn off compression and clear the cache?

kenorb’s picture

Problem is clear up when I'm turning off compression or clearing the cache.
Probably I've manage to dump database when this problem appeared again, I'll try to analize it a little.

kenorb’s picture

I don't know it's normal, but in those database some of the pages are normal like that:

INSERT INTO `cache_page` VALUES ('/download','<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\r\n<html xmlns=\"http://www.w3.org/1999/xhtml\" lang=\"en-GB\" xml:lang=\"en-GB\" dir=\"ltr\">\r\n<head>\r\n  <title>Title</title>\r\n  <meta http-equiv=\"Content-Style-Type\" content=\"text/css\" />\r\n  <meta http-equiv=\"Content-Type\" content=\"text/html; charset=utf-8\" />\n<meta name=\"robots\" content=\"index,follow\" />\n
(rest of the page)
</html>',-1,1226867781,'Content-Type: text/html; charset=utf-8',0),

And some other VALUES are like:

('/sitemap','‹\0\0\0\0\0\0ÍZ{sÛ6ÿ;ž¹ï€pæžSŠz8räHê$vÒÜœÛóùÑö¦ÓÑ@(Â	–„îÝ}÷ÛH\nÔÃQ|N®JLƒØÅ¾\0üvyøüüïg7ÿ¼|KbHryûæâ¯gÄóƒà‡ÞYœßœ“ßß|{A:­6¹ÉiZ-TJe¼ýÎ#^¬uv\ZËå²µìµT>n®‚Êêàà²ékgd‹iæw44\ZW‰L‹Ñ9Á``‡{DÒt6òxêóÆÃ§&ò‘\'un…rÊà7!C-´äãk¡9IhFþM.©LÞ+Íåí߆¥\ZÆ„kJÐ\0Ÿÿ2‹‘w¦RÍSí_ë{Éý›ûŒ{$´}#Oó•¢ðHð‘Ợ?¯HÓ¼àz4בÿY))MøÈËÕTéÂ)RÆW_EJJµÜâ>?k_~ÇQË.Eúä\\޼\"V¹çšàöHœóhä‰( ¢ìlÁÃ#\ZlÅ	ñ`å[fî\ZY–¼…•á*bεGÎyTÊZ	Ì?/Æ#:—:ˆðâà`ð²…ôøä„O§\'¼Ýé½è@Ož½—|Êy«6*/Â\\dÚUGÔöz¤ÈÃÊ™»_æ<¿oÝ_¯¼ñ0°‰ƒ°|žÁZ}”\0ë)ø$ŠÍÑOF57‰	ÿU¥oO¥G$³	-\nQh§ù
(rest of the compressed page)
¸\n»¹J\"\0\0',-1,1226865701,'Content-Type: text/html; charset=utf-8',0),

So it's weird that some of them are already compressed, even the header says that it should be text/html.
Or another example:

('http://www.example.com/sites/all/themes/theme034/images/bg-li3.gif','‹\0\0\0\0\0\0­WmoÛ6þœ\0û,\rPšvÒ¦u\"iHìl–nYë`Š\" %JbJ‰*EÅö^þûŽz3•¸YWTlм»çîx|Žö͝-þ¸<G©É$º¼:»øi†0¡ô÷Ã¥óŽy±xy&£1Zh–—•3Iéù/áÔ˜â˜ÒÕj5ZŽ”Nèâ][[«Ü
(rest of the compressed page)
°}<VÊôÝØ>—jÜ¡³Í1‚ú†\'pÛÆ×KøÏ𾻐:7ÖÀ…äîš*£8x3kߝº½ïÈÖM¶·¯¾àÿ´±“R\r\0\0',-1,1226924107,'Content-Type: text/html; charset=utf-8\nHTTP/1.1 404 Not Found',0),
Mike_Waters’s picture

Well, that is definitely gzip data (the first two bytes, per rfc1950, are 0x1f8b, which is what you've displayed).
You've got a bug somewhere.

kenorb’s picture

Status: Postponed (maintainer needs more info) » Active
StatusFileSize
new78.15 KB

The first characters I've got: "1F 8B 08", so gzip header is ok.

ainigma32’s picture

Status: Active » Postponed (maintainer needs more info)

@kenorb: Did you ever figure out what was/is going on?

- Arie

kenorb’s picture

No. I've no idea. I'd to disable all cache on those websites.

ainigma32’s picture

@kenorb: Since it looks like this problem was caused by one of the contributed modules I think this issue should either be reassigned to the queue of the offending module or this issue should be set to fixed (or maybe won't fix)

What do you think?

- Arie

kenorb’s picture

Status: Postponed (maintainer needs more info) » Postponed
kenorb’s picture

Status: Postponed » Closed (duplicate)