Server has broken PHP functions

Hi Jeff,

Do you know what are the option values you set for the list field "category"? For example is it text or from another table or from a mysql query? You should be able to check the setting under the section editor and click modify for the "category" field. I think the errors show up because getListOptionsFromSchema() function didn't process correctly and threw an error.

There is no list field at all. It appears to be a header request only.

see:

https://www.interactivetools.com/forum/forum-posts.php?postNum=2238686#post2238686

Also see:

errorlog_functions.php starting at line 483

// returns a text warning if broken PHP functions are detected on server, or blank otherwise
// detect servers with broken print_r (Seen July 2015 on 1&1 UK Shared Hosting Package occurs
// ... on HEAD request after any content sent, and causes our error logs to be blank!
// These errors can be recreating by sending a HEAD request from the command line with curl
// ... as follows: curl -I https://www.example.com/
function _errorlog_getBrokenPhpFunctionsWarning() {

The issue is it is filling up the logs and firing emails all day long.

Hi Jeff, 

You can disable that function by adding this code to the top of /lib/errorlog_functions.php

// enable error logging
if (isInstalled()) {
  if ($_SERVER['REQUEST_METHOD'] != 'HEAD') { // prevents HEAD request errors being logged from _errorlog_getBrokenPhpFunctionsWarning()
    errorlog_enable();
  }
}

I'll add that code (commented but there) for future releases.  

The underlying issue is that when the server receives a HEAD request some of the PHP functionality doesn't work correctly.  We've never been able to identify the root cause of this but it's likely related to something to do with the server configuration.  The above change just disables the logging of the errors.  There will still be errors caused by the software not operating correctly because PHP functions aren't working.

Hope that helps, let me know any questions!

I had a few hours to investigate this a bit,

The problem does not exist with php 7+ because php does not get executed at all when only a head request is sent.

With php 5.6, the code is executed. I added the following to the beginning of my initialization sequence before calling the viewer functions.

if ($_SERVER['REQUEST_METHOD'] === 'HEAD') {
    header('html/text');
    exit;
}

Everything worked as expected.

I used Xdebug to show that this line does not run in 7+ and has no negative impact on 5.6 as the exact same header is returned with or without this snippet.

Ok, can you let me know if that causes any issues over time? 

My concern with disabling HEAD requests is that it's a valid part of the HTTP protocol, so browsers might send a HEAD request to see if a resource has changed without needing to get the content.  

See: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

9.4 The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext links for validity, accessibility, and recent modification.

So it should execute PHP regardless.  HEAD requests are also often used by server uptime checkers, etc.

In any case, let me know how it goes.