Make services outage page send an appropriate http status code

VERIFIED FIXED

Status

VERIFIED FIXED
11 years ago
6 years ago

People

(Reporter: mossop, Assigned: reed)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

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?
(Reporter)

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: addons.mozilla.org → mozilla.org
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>
    ServerName outages.mozilla.com
    ServerAlias outage-org.nslb.sj.mozilla.com
    ServerAlias addons.mozilla.org
    DocumentRoot /data/www/outages.mozilla.com
    <Directory /data/www/outages.mozilla.com>
        SetEnv SERVER_NAME outages.mozilla.com
        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
    </Directory>
</VirtualHost>
So the end result is the content at http://www.mozilla.com/en-US/outages.html.
So why not a 503 instead of a 200 OK?

Given:
        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 mozilla.com component for the fixes?
(Assignee)

Updated

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

Comment 12

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

Sending        outages.html
Transmitting file data .
Committed revision 13212.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
(Reporter)

Comment 14

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

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 outages.mozilla.com.
(Assignee)

Comment 17

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

http://web-sniffer.net/?url=http%3A%2F%2Fwww.mozilla.com%2Fen-US%2Foutages.html&submit=Submit&http=1.1&gzip=yes&type=GET&uak=0:

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