HTTP Status Codes

[Sorck]

Makes sure all HTTP status codes provided HTTP response headers are correct for the version of HTTP being used.

Also utilises the centralised function send_http_status in Errors.php to make sure the HTTP version determining code is centralised.

Resolves #4832

[albertlast]

To use send_http_status is in my eyes not the right approache,
because this function is not everywhere defined.

[Sorck]

send_http_status is defined in Errors.php which loaded on every page load (wether from /index.php or /SSI.php). It's also available before any SMF functions are called so it is defined everywhere it's being used.

[albertlast]

nope see proxy.php
Why you choose to take this risk instead of place the vars ther?

[Sorck]

Inlining it in over 20 places will be verbose and harder to maintain than a centralised function.

The best solution would be moving send_http_status from Errors.php to Subs.php. Subs.php is a more natural home for the function as send_http_status has a similar use to redirectexit.

[albertlast]

Since we use this on many early stages and error cases etc.
i would be for to keep the decentralize concept and use the var methode instead of a function approache.

[Sorck]

It's possible for SERVER_PROTOCOL to hold a few different values according to RFC 3875 and we need to default to HTTP/1.0 if we don't know the protocol. So the following is not guaranteed to work:
header($_SERVER['SERVER_PROTOCOL'] . " 500 Internal Server Error");

So we need to check the protocol using a preg_match which will look like this each time (if we assume that there could be excess whitespace on the protocol):
header((preg_match('~^\s*(HTTP/[12]\.\d)\s*$~i', $_SERVER['SERVER_PROTOCOL'], $matches) ? $matches[1] : "HTTP/1.0") . " 500 Internal Server Error");
Or
header(preg_match('~^(HTTP/[12]\.\d)$~i', trim($_SERVER['SERVER_PROTOCOL'])) ? $_SERVER['SERVER_PROTOCOL'] : "HTTP/1.0") . " 500 Internal Server Error");

Compared with my proposed version:
send_http_status(500);

With the function in Subs.php it is available in all cases before any SMF function calls. If defined there then it is definitely loaded whether in early stages or in an error cases.

[jdarwood007]

https://serverfault.com/questions/442960/nginx-ignoring-clients-http-1-0-request-and-respond-by-http-1-1

According to the mentioned RFCs, this really shouldn't be a issue.

Browsers seem to indicate that they support http2 as well:
https://en.wikipedia.org/wiki/HTTP/1.1_Upgrade_header#Use_with_HTTP/2

I can't find confirmation, but I believe that means that servers should be sending back the proper header info if supported?

[jdarwood007]

Your sending a double header here.

[jdarwood007]

Also this function could call http_response_code if its available (5.4 or higher needed) as it can handle most cases better than the built in function.

As well header does have a 3rd param that also works here for sending a status code.

[MissAllSunday]

We have set 5.4.0 as min for SMF 2.1 so we should be on the safe side when using http_response_code() but do a check for http_response_code() availability and leaving the in-house solution doesn't do any harm.

[jdarwood007]

@Sorck Can you fix the double header issue and we can merge these. Implanting the built in php http_response_code is optional.

[MissAllSunday]

Double header removed.