4

Still facing a weird issue with Google Chrome. I have a text/html page generated from a php source code. This page loads well and is well displayed on any popular browsers but Chrome. When the source code has just been saved, Chrome loads and render the file the right way. Even if I simply added or removed a space character. Next, if I try to refresh the page, Chrome displays a blank page and shows an error in the Developper Tools panel (see screenshot) indicating a "failed" status. But if I check the HTTP response headers, everything seems to be fine, including the HTTP status: 200 OK.

HTTP/1.1 200 OK
Date: Mon, 17 Sep 2012 08:37:03 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.3.14
Expires: Mon, 17 Sep 2012 08:52:03 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

Bellow is the HTTP response headers just after saving the source and getting a correct rendering. No change (except time related information)

HTTP/1.1 200 OK
Date: Mon, 17 Sep 2012 08:56:06 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.3.14
Expires: Mon, 17 Sep 2012 09:11:07 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

I also checked the HTTP request headers, they are the same in both cases:

Working case:

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4
Cache-Control:max-age=0
Connection:keep-alive
Cookie:PHPSESSID=qn01olb0lkgh3qh7tpmjbdbct1
Host:(hidden here, but correct, looks like subsubdomain.subdomain.domain.tld)
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89 Safari/537.1

Failing case:

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4
Cache-Control:max-age=0
Connection:keep-alive
Cookie:PHPSESSID=qn01olb0lkgh3qh7tpmjbdbct1
Host:(also hidden)
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89 Safari/537.1

I noticed that even if the page failed, some other resources (javascript, style sheets) are successfully loaded or retrieved from the local cache. I can also access the HTML source code successfully every time, could the page be rendered or not (the HTML code is what it's expected to contain).

I also ran Wireshark in order to see if there would be something wrong while transferring data or something, but everything seems to be OK on this side too.

I read something on Google about content-length that would make Chrome fail if the information provided in the HTTP headers differs from the effective size of the delivered file. It does not seem to me it would be the case here as content-length is not provided.

Any help would be welcome! Thanks!

MaxAuray
  • 513
  • 1
  • 4
  • 18
  • I updated PHP to its latest version and I begin to have information I had not with previous version: [Mon Sep 17 16:19:42 2012] [notice] child pid 8017 exit signal Segmentation fault (11) Seems there is also something wrong with Doctrine as, for this particular page ONLY, if I remove usage of Doctrine for this object, the issue disappear. But this does not explain why is this issue Chrome specific (client side) and it generates an error on Httpd/PHP (server side). No such problem with other browsers... – MaxAuray Sep 17 '12 at 14:23
  • I'm having the same problem. I don't suppose you ever found out why Chrome was failing, did you? – DavidA Feb 13 '13 at 18:53

1 Answers1

2

To those who are still encountering the issue: add setEnv downgrade-1.0 to your .htaccess, for me it works as temporary fix. It disables chunked transfers.

Another solution is to set user agent to IE, apparently it does the same...

Actual issue is somehow related to server configuration, I am also seeing segmentation fault errors. Site I am encountering this behaviour runs on PHP 5.3.27 over HTTPS.

edit: It doesn't matter if site is accessed over HTTPS or HTTP.

edit2: The cause for this error was one extremely long line, splitting it into multiple lines solved the problem.

FDIM
  • 1,981
  • 19
  • 21
  • Thanks for your edit2 suggestion. I had the same issue with a long base64 encoded line in CSS. The file was served on a WIndows machine (localhost), but when deployed on a linux machine, the css file resulted empty. To break a long css line in multiple lines see: http://stackoverflow.com/questions/11398205/base64-background-image-in-multiple-lines – singe3 May 13 '15 at 12:33