Fixed Return HTTP 503 causes XenForo to be virtually unusable behind a loadbalancer

I've reported this before because I wanted to set up social connected accounts, which need to verify an existing privacy policy. While I believe the privacy policy is still visible when the board is closed, it will automatically be rejected by Google and Facebook because of a 503 and not a 200.

I was told that the 503 is as designed.

But hopefully, with this new finding, an option to 200 a closed board is implemented for this and new boards to prep a launch with connected accounts as verification can be automatic to days.

xenforo.com

As designed - 2.1 Beta 5 - Board is active - Error 503?

I'm unsure if this is intentional or not, but kicking a 503 as opposed to the 200 causes errors when you require 3rd party tools to check your site for various things. How to replicate: ACP -> Options -> Board active -> Uncheck "Board is active" : Get error 503 (page still renders, but 3rd...
xenforo.com xenforo.com
 
503 is becoming a standard code for maintenance purpose and other cases where services are disrupted.
I think you need to custom error code yourself to meet your demand. My uptime tracker won't like it being always 200 code when the forum is actually closed / down.
 
This makes XenForo basically unusable out-of-the-box behind loadbalancer from say google cloud's, AWS, Linode, Digitalocean, etc. While Clouldflare's web proxy stuff is unaffected, if you use their loadbalancer product it gets affected.

Making the difference between an XenForo's 503 when the site is soft-disabled and an intermediary webserver 503 jumps from simple to quite hard

Worse throwing 503s errors when the XenForo is actually usable and in-fact is required to be administered in that state, means you would be forced to hand-write body response body regex tests. Which are entered differently on every loadbalancer product compared to built-in http status check.

Or just edit every reference to a 503 to something like a 200 or 404 and deleted/edit hashes.json and have a much saner experience.
 
Last edited:
Xon said:
While Clouldflare's web proxy stuff is unaffected
Click to expand...
It brought my site down:
xenforo.com

Board Offline Status code causes sites on CloudFlare to go down and become unreachable

I'm not sure if this is a issue or a suggestion. When you turn off your site and upgrade XenForo then it will return a 5.xx status code. If you run CloudFlare then this will go into a spasm over that status code, as it considers your server unreachable. The CF admin panel fills up with all...
xenforo.com xenforo.com
Chris D said:
It’s the appropriate response code because it means “Service unavailable”.
Click to expand...
That depends on the interpretation of what service is unavailable. If no service would be available then there would be no admin panel to upgrade. So obviously there is a service available. Just not the normal forum content. A no permission page does not give a 503 either. I don't think a 503 code is a logical decision.

Especially not considering how disruptive this is. It brings you site down in the middle of an upgrade.

And I may be wrong about this, but it seems to me that interrupting an upgrade could cause database issues, corruption, etc. Which is even scarier than bringing your site down.

Please consider to change this status code as it is way too unfriendly for webmasters and has unwanted results.
 
Alfa1 said:
That depends on the interpretation of what service is unavailable. If no service would be available then there would be no admin panel to upgrade. So obviously there is a service available. Just not the normal forum content. A no permission page does not give a 503 either. I don't think a 503 code is a logical decision.
Click to expand...
A no permission page doesn't give a 503, because that would be an inappropriate response code. No permission gives a 403 "Forbidden" or 401 "Unauthorized" response. It's a bit of a strawman argument.

We still 100% stand by the fact that 503 is correct. The "service" is your forum and there are certain times where that becomes "unavailable" temporarily. That is what the 503 response is for.

200 seems wholly inappropriate for a number of reasons. 200 is "success" and a site that isn't functioning fully is hardly a successful request. Pretty sure there could be an element of a 200 response being a success being cached and returned to users, potentially long after the site has fully opened again.

That said, we're open to compromise. The only workable way I can see to compromise right now is to make the "service unavailable" response code to be configurable. We still default it to 503, but you could override it in src/config.php to something more compatible with whichever systems you have in place.

PHP: 
$config['serviceUnavailableCode'] = 200;

Would that work for everyone?
 
Chris D said:
That said, we're open to compromise. The only workable way I can see to compromise right now is to make the "service unavailable" response code to be configurable. We still default it to 503, but you could override it in src/config.php to something more compatible with whichever systems you have in place.

PHP: 
$config['serviceUnavailableCode'] = 200;

Would that work for everyone?
Click to expand...
Sounds like a plan :)
 
Chris D said:
That said, we're open to compromise. The only workable way I can see to compromise right now is to make the "service unavailable" response code to be configurable. We still default it to 503, but you could override it in src/config.php to something more compatible with whichever systems you have in place.

PHP: 
$config['serviceUnavailableCode'] = 200;

Would that work for everyone?
Click to expand...
Yes, most definitely. Thanks!
 
Thank you for reporting this issue. It has now been resolved and we are aiming to include it in a future XF release (2.1.3).

Change log:
Add a new config key serviceUnavailableCode (defaults to 503) which represents the response code returned when parts of the site are unavailable.
Click to expand...
Any changes made as a result of this issue being resolved may not be rolled out here until later.
 
Mouth said:
Would have saved me some time if this was listed within https://xenforo.com/docs/xf2/config/
The Docs page says "The following is a list of all settings that can be controlled through config.php.", but it's not all settings :unsure:
Is there a definitive list of all?
Click to expand...
It's missing a decent amount, unfortunately. It's worth going through the config options in the code itself to see what's actually available for your version, although some config options are vestigial and may break the site, so test them first before putting them live.

As I side note--and I know I'm beating a dead horse here--but 503 is the correct response code when your board is closed. Most mainstream load balancers now allow you to configure success status codes. Returning 200 runs the risk of various undesirable side-effects, such as search engines indexing things they shouldn't. Google in particular expects 503 for planned maintenance.[1][2] If you have the option to use the default rather than changing this config option, you should probably do so. It's also probably best to disable health checks while performing planned maintenance, but that's another can of worms.
 
Back
Top Bottom