Make services outage page send an appropriate http status code



11 years ago
6 years ago


(Reporter: mossop, Assigned: reed)


Firefox Tracking Flags

(Not tracked)





11 years ago
Not sure this is the right place for this but the blocklist service is on AMO so...

It seems that in times of outage the blocklist service returns a Service Outages page like most of mozilla's webservers. Unfortunately it is returned as a regular page with 200 status code. This causes the blocklist service to assume it has been fed valid data and saves it to the users profile. This doesn't cause a major issue, the invalid page is just ignored, but it does mean that for the next day the user is without any blocklist.

It would seem to me that a services outage page should be sent with something other than a 200 status code, possibly a 503, but I'm not really sure. Basically we should be properly indicating that the service failed.
There is a disabled page built in to AMO but I don't think it's ever been used in production.  I think IT usually just changes the apache config to point elsewhere.  CCing oremj.
Dave does the client look for a particular code?

Comment 3

11 years ago
The code looks for a status of 200 before assuming the data it has received is correct.
Target Milestone: --- → 3.4
Jeremy - what happens in the event of an outage?
-> IT for feedback.
Assignee: nobody → server-ops
Component: Blocklisting → Server Operations
Product: →
Target Milestone: 3.4 → ---
Version: unspecified → other
In the event of an outage the backend servers get switched to the static cluster.  The following vhost gets put in use:

<VirtualHost *:80>
    DocumentRoot /data/www/
    <Directory /data/www/>
        SetEnv SERVER_NAME
        RewriteEngine On
        RewriteCond %{SCRIPT_FILENAME} !^.*\.(js|css|png|jpg)$
        RewriteCond %{SCRIPT_FILENAME} !^.*prefetch.php$
        RewriteRule .* en-US/outages.html
        Action init /includes/prefetch.php
        AddHandler init .html
        ErrorDocument 403 /includes/prefetch.php
        ErrorDocument 404 /includes/prefetch.php
So the end result is the content at
So why not a 503 instead of a 200 OK?

        RewriteRule .* en-US/outages.html

During an outage people will think the page they got back was normal, and that's what this bug is about -- mismatched expectations.  :D
We could set the status via the rewrite rule to 503, but it would probably be a better idea just to set 503 in en-US/outages.html (since it is really getting processed as php). 
I think that's all we need, unless there's a reason not to have it.
Should this be moved to the component for the fixes?


11 years ago
Assignee: server-ops → reed
Component: Server Operations →
Product: → Websites
QA Contact: blocklisting → www-mozilla-com
Version: other → unspecified

Comment 12

11 years ago
 header('HTTP/1.1 503 Service Temporarily Unavailable');
 header("Retry-After: 120");

Sending        outages.html
Transmitting file data .
Committed revision 13212.
Last Resolved: 11 years ago
Resolution: --- → FIXED

Comment 14

10 years ago
Seems to be giving a 200 code right now using the test in comment 13
Resolution: FIXED → ---
Looks like reed backed this out 4 months ago, not sure why.  Reed?

Comment 16

10 years ago
(In reply to comment #15)
> Looks like reed backed this out 4 months ago, not sure why.  Reed?

It killed the NetScaler at the Firefox 3 launch. I think we can add this back now, but I'm pretty sure the outages page has moved to

Comment 17

10 years ago
r13212 added it. r15972 removed it. r19843 added it back.
Last Resolved: 11 years ago10 years ago
Resolution: --- → FIXED
Verified FIXED; thanks for pushing to prod, Wil.

HTTP Status Code: HTTP/1.1 503 Service Temporarily Unavailable
Component: →
Product: Websites → Websites
Component: → General
Product: Websites →
You need to log in before you can comment on or make changes to this bug.