Forum

Just ran across this issue with running a Drupal website. After getting everything setup for a Drupal website, I would get a white screen after revisiting a page on the website.

I tracked down the issue to the CGI response from the PHP FPM server. I could see that a 304 (Not modified) response was being sent back to Hiawatha, but Hiawatha was responding to the browser client with a 200 status code, causing the browser to assume it was receiving content when actually none was sent because the browser should already have it.

A little bit of searching dug up the following link which confirmed my suspicion that there was a miscommunication between Drupal and Hiawatha.
https://github.com/symphonycms/symphony-2/issues/972

In the /includes/bootstrap.inc (line 1326 of v7.41) there is the following line:

    header($_SERVER['SERVER_PROTOCOL'] . ' 304 Not Modified');

Changing that line to the following seems to have solved the problem.

    header('Status:' . ' 304 Not Modified');

Are you still using version 7 of Hiawatha? Hiawatha was updated quite a while ago to deal with the HTTP-style status-setting, so I think this should no longer be an issue when running latest stable Hiawatha.

Nope, running the latest - 10.0.

I'm guessing I have you to thank for the Symphony issue above?

The "header($_SERVER['SERVER_PROTOCOL']" part is wrong anyway, since the first line of a response should always say "HTTP", never "HTTPS". This is a bug in Symphony.

Did some more debugging and figured out its a combination of request headers:

If-Modified-Since:
If-None-Match:
Accept-Encoding: gzip, deflate

Any of them work fine by themselves or with only one of the other, but when you add all three together you stop getting content sent.

testuser$ curl -v -H 'If-Modified-Since: Thu, 04 Feb 2016 05:06:44 GMT' -H 'If-None-Match: "1454562404-1"' -H "Accept-Encoding: gzip, deflate" http://www.example.com/about_us
*   Trying 127.0.0.1...
* Connected to www.example.com (127.0.0.1) port 80 (#0)
> GET /about_us HTTP/1.1
> Host: www.example.com
> User-Agent: curl/7.43.0
> Accept: */*
> If-Modified-Since: Thu, 04 Feb 2016 05:06:44 GMT
> If-None-Match: "1454562404-1"
> Accept-Encoding: gzip, deflate
> 
< HTTP/1.1 200 OK
< Date: Thu, 04 Feb 2016 05:31:49 GMT
< Server: Hiawatha
< Connection: keep-alive
< Transfer-Encoding: chunked
< HTTP/1.1 304 Not Modified
< X-Drupal-Cache: HIT
< Etag: "1454562404-1"
< Cache-Control: public, max-age=0
< 
* Connection #0 to host www.example.com left intact

Notice the extra "304 Not Modified" header. I verified with the PHP log that the FastCGI server is returning a status response code of 304. I can't tell if Hiawatha is adding the 200 status header or if Drupal is sending it along with the 304.

Below is a response for only two of the headers. In this case the FastCGI server is sending a 200 response code as well as the content.

testuser$ curl -v  -H 'If-None-Match: "1454562404-1"' -H "Accept-Encoding: gzip, deflate" http://www.example.com/about_us > gzip2
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 127.0.0.1...
* Connected to www.example.com (127.0.0.1) port 80 (#0)
> GET /about_us HTTP/1.1
> Host: www.example.com
> User-Agent: curl/7.43.0
> Accept: */*
> If-None-Match: "1454562404-1"
> Accept-Encoding: gzip, deflate
> 
< HTTP/1.1 200 OK
< Date: Thu, 04 Feb 2016 05:44:19 GMT
< Server: Hiawatha
< Connection: keep-alive
< Transfer-Encoding: chunked
< X-Drupal-Cache: HIT
< Etag: "1454562404-1"
< Content-Type: text/html; charset=utf-8
< Content-Language: en
< Link: </node/1>; rel="shortlink",</about_us>; rel="canonical"
< X-Generator: Drupal 7 (http://drupal.org)
< Cache-Control: public, max-age=0
< Last-Modified: Thu, 04 Feb 2016 05:06:44 GMT
< Expires: Sun, 19 Nov 1978 05:00:00 GMT
< Vary: Cookie
< Vary: Accept-Encoding
< Content-Encoding: gzip
< 
{ [1148 bytes data]
100  4062    0  4062    0     0  36763      0 --:--:-- --:--:-- --:--:-- 36927
* Connection #0 to host www.example.com left intact

Set cgi.rfc2616_headers to 0 in php.in to solve the header issue.

Well that would seem to do it! Its funny (ok, not really) because I checked multiple times in php.ini to make sure it was set to 1. Maybe you could add something in the documentation for future users?

Thanks!

I've made some changes to Hiawatha. It can now also deal with the headers as send with 'cgi.rfc2616_headers=1'.

Excellent, thank you!

Do you have a working repository available to the public or do you only upload to github when you release?

It's available in the v10.1-beta release.

I can confirm after some testing that the problem has been solved and the website works correctly with the cgi.rfc2616_headers set to 0 or 1.

Thanks!

Thanks for testing!