not returning response code from header()

[jamesrwhite]

Every now and then when using HHVM under the new FastCGI mode an empty response is returned from my WordPress site. This doesn't seem to be a code error on my side though as it happens very infrequently and nothing is in the error log and the response code is 200.

My HHVM config is as follows:

Log {
  Level = Verbose
  UseLogFile = true
  File = /var/log/hhvm/error.log
  Access {
    * {
      File = /var/log/hhvm/access.log
      Format = %h %l %u %t \"%r\" %>s %b
    }
  }
}

When this issue occurs all that's shown in the error log is: 'receiving index.php'

This is only really a guess but I think this issue may be related to HHVM's interpretation of the HTTP headers sent by the client. I noticed that when I had my chrome developer console open I could never reproduce the issue. I think this may be have been because I have mine configured so that when the console is open Chrome never shows cached content. And example of this can be seen below, when I send the exact same request via curl that Chrome sent I can continually reproduce the issue but as soon as I do a hard refresh in the browser or send a standard curl request I get the expected response.

See: https://gist.github.com/jamesrwhite/8073803

Let me know if there's any additional information I can provide to help :)

[jamesrwhite]

I've also just seen this in the access log, when an empty response is returned the HHVM access log has the status code marked as being 304 but that doesn't seem to be being passed to nginx (which is sitting in front of hhvm) as that still returns a 200 so I guess that's why no content is returned!

hhvm access log:

 - - [21/Dec/2013:19:28:09 +0000] \"GET / HTTP/\" 200 98306
 - - [21/Dec/2013:19:31:24 +0000] \"GET / HTTP/\" 304 -
 - - [21/Dec/2013:19:33:51 +0000] \"GET / HTTP/\" 304 -
 - - [21/Dec/2013:19:33:54 +0000] \"GET / HTTP/\" 304 -

nginx access log:

my.ip.address - - [21/Dec/2013:19:28:09 +0000] "GET / HTTP/1.1" 200 98399 "-" "curl/7.30.0"
my.ip.address - - [21/Dec/2013:19:31:24 +0000] "GET / HTTP/1.1" 200 5 "http://beta.postdesk.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36"
my.ip.address - - [21/Dec/2013:19:33:51 +0000] "GET / HTTP/1.1" 200 5 "http://beta.postdesk.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36"
my.ip.address - - [21/Dec/2013:19:33:54 +0000] "GET / HTTP/1.1" 200 5 "http://beta.postdesk.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36"
my.ip.address - - [21/Dec/2013:19:34:32 +0000] "GET / HTTP/1.1" 200 5 "http://beta.postdesk.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36"

My nginx config to send the requests to HHVM is basically exactly as it was when I was using PHP-FPM previously:

        location ~ \.php {
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_pass  127.0.0.1:9999;
                fastcgi_index index.php;
        }

[ElectroLutz]

I had the same problem. You have to change the header which is sent for statuscodes. There are different answers on that problem on the net. Some say "pass the statuscode (int) as the 3rd parameter to header()", some say "change the statuscode-Message from HTTP/x.x to Status". The first one didn't work for me with HHVM (Wordpress does this already). But since there are different answers on that problem, I'm not sure if HHVM is missing this feature or Wordpress is missing a working header implementation for fastcgi.

But for now the following snippet solved the problem for me:

add_filter('status_header', 'fastcgi_status');
function fastcgi_status($header) {
    return preg_replace('@HTTP/1.[0-9]@', 'Status:', $header);
}

(I placed this in a custom plugin I wrote for my blog)

[jamesrwhite]

Thanks for the reply. I tried that but unfortunately it doesn't seem to solve the issue. I think it either has to be an issue with HHVM or I've somehow set it up incorrectly :(

I set up the following test script:

<?php

header('HTTP/1.1 304 Not Modified', true, 304);
echo 'Hello World';

it works as expected when run under nginx/PHP-FPM but not under nginx/HHVM

james at air in ~
» curl -IL http://www.postdesk.com/headers.php
HTTP/1.1 304 Not Modified
Server: cloudflare-nginx
Date: Sun, 22 Dec 2013 00:42:14 GMT
Content-Type: application/octet-stream
Connection: keep-alive
Set-Cookie: __cfduid=d7b35b188b0920e8bae6dabc3fd44119a1387672934762; expires=Mon, 23-Dec-2019 23:50:00 GMT; path=/; domain=.postdesk.com; HttpOnly
CF-RAY: e08c562403306fa

james at air in ~
» curl -IL http://beta.postdesk.com/headers.php
HTTP/1.1 200 OK
Server: nginx
Date: Sun, 22 Dec 2013 00:42:18 GMT
Connection: keep-alive
X-Powered-By: HPHP

[ElectroLutz]

Did you try your test script with the following header?

Status: 304 Not Modified

This should solve the problem for now. But I guess HHVM is missing the functionality of the 3rd parameter in fastcgi mode.

[jamesrwhite]

That does fix it in my test script yes but I think I'll have to dig a bit deeper to see how to fix it on my WordPress site. Depending on whether the page is cached or not the status code can be set from a number of different places.

I agree though, I think ultimately this is still a HHVM issue, this site worked perfectly under another fastcgi server (PHP-FPM).

[scannell]

Thanks for reporting this and the investigation. This looks like a real bug. @ptarjan may have fixed it already but I'm not sure and he's on holiday. (Does it repro in master?) He should comment when he's back though.

[ptarjan]

Nice, good diagnosing. Does your small repro case work when HHVM is the frontend server (without the -vServer.Mode=fastcgi)?

It might be a header bug in fastcgi. If you want to try and fix it, the fastcgi stuff is all in a separate directory so it should be easy to dig in to. If you don't find a fix, I'll look at it in 2 weeks when I'm back.

[jamesrwhite]

Thanks for the replies, I've updated to 2.3.2 but that doesn't seem to help this issue. Running it with HHVM as the frontend works perfectly though, so as you said it looks to be a fastcgi specific issue. I've had a quick look at the fastcgi directory but I'm not too familar with c/c++ so I'm not sure I can be much use there.

[jamesrwhite]

I'm sure this does fix the issue but I'll have to wait for the next pre-built release to confirm, I've run into too many problems when I've tried build from source. Thanks :+1:

[rami-dabain]

Am having this issue as well under OXID shop

[ptarjan]

@rami-dabain with what version of hhvm?

[rami-dabain]

latest version for ubuntu 12.04 installed from the repo today, and i tried the nightly build, same issue. nothing in the error logs installed hhvm for ISPConfig here from this page http://blog.noczone.com/?p=102 works good for most of websites, but the most important website runs on OXID shop, it didn't work for "some" pages

Kind regards , Rami Dabain

On Wed, Mar 12, 2014 at 6:49 PM, Paul Tarjan notifications@github.comwrote:

@rami-dabain https://github.com/rami-dabain with what version of hhvm?

Reply to this email directly or view it on GitHubhttps://github.com/facebook/hhvm/issues/1416#issuecomment-37440562 .

[ptarjan]

@rami-dabain well, this issue was for sure closed in 2.4.0 so it isn't the same problem. Please open another issue and we'll need much more info to help diagnose. Sadly the only way to deal with white pages I've found has been to bisect deleting code until you find the one function that is fataling the page.

[rami-dabain]

ok, will dig more into it and open a ticket when i find something thanks

Kind regards , Rami Dabain

On Wed, Mar 12, 2014 at 7:02 PM, Paul Tarjan notifications@github.comwrote:

@rami-dabain https://github.com/rami-dabain well, this issue was for sure closed in 2.4.0 so it isn't the same problem. Please open another issue and we'll need much more info to help diagnose. Sadly the only way to deal with white pages I've found has been to bisect deleting code until you find the one function that is fataling the page.

Reply to this email directly or view it on GitHubhttps://github.com/facebook/hhvm/issues/1416#issuecomment-37442146 .