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

Affected version
2.1

frm

Active member
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.

 

Banxix

Active member
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.
 

Chris D

XenForo developer
Staff member
It’s the appropriate response code because it means “Service unavailable”. Your load balancer would need to be configured somehow to accept it.
 

Xon

Well-known member
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:

Alfa1

Well-known member
While Clouldflare's web proxy stuff is unaffected
It brought my site down:
It’s the appropriate response code because it means “Service unavailable”.
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.
 

Chris D

XenForo developer
Staff member
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.
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?
 

Kirby

Well-known member
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?
Sounds like a plan :)
 

Alfa1

Well-known member
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?
Yes, most definitely. Thanks!
 

XF Bug Bot

XenForo bug fixer bot
Staff member
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.
Any changes made as a result of this issue being resolved may not be rolled out here until later.
 
  • Like
Reactions: frm
Top