Open Bug 230260 Opened 18 years ago Updated 1 month ago

Retry-After sent with HTTP 503 response is ignored

Categories

(Core :: Networking: HTTP, enhancement, P3)

x86
Windows 2000
enhancement

Tracking

()

People

(Reporter: boozai, Unassigned)

Details

(Keywords: dev-doc-needed, Whiteboard: [necko-backlog])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

A web server that returns the 503 status code "Service Unavailable", sometimes
also specifies the "Retry-After" field in the header.
This is not handled by Firebird.
That case gives the ability to the client to retry automatically the query in a
cooperative way.
This has benefits on the client side (the page eventually loads after a few
attempts), and on the server side (it limits the slashdot effect on a server for
example, were people keep hiting the reload button).
The patch should be fairly simple, as it's the same code than 302 "Redirect",
except the query is the same one than before (and not a new query).


Reproducible: Always

Steps to Reproduce:
Point to a server that returns the 503 code with a retry-after field

Actual Results:  
Firebird stops loading as soon as it gets the answer, ignoring the retry-after field


Expected Results:  
Firebird should have tried to load the page until the global timeout is reached

There is no real workaround for this other than hitting the "reload" button over
and over, and that's a shame considering that all elements are present for the
browser to do it for us!
we have an atom for it, but no consumers...
Assignee: bugs → darin
Component: Downloading → Networking: HTTP
Product: Firebird → Browser
QA Contact: httpqa
Version: unspecified → Trunk
interesting, ok.  is there a spec somewhere for this field?
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: HTTP status code 503 "Service Unavailable" not handled properly → Retry-After sent with HTTP 503 response is ignored
Target Milestone: --- → Future
ok, i found a reference to the header here:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.37

it is an optional element, but i agree that we should implement it.  it wouldn't
be hard to implement either.
Status: NEW → ASSIGNED
Whiteboard: [http/1.1]
This could be useful for 3xx redirects as well.  The specification indicates this is a "MAY", but if it were more widely supported, with the redirection response content displayed before the redirect was actually performed, it could eliminate the last meaningful reason people cling to HTML meta refresh.

Could the 3xx case be folded into this bug, or should it be opened as a separate bug?
Yes, that sounds like a good idea.
Assignee: darin → nobody
Status: ASSIGNED → NEW
Target Milestone: Future → ---
4.5 years later, the browser has changed names but the feature hasn't been implemented.

From my testing, 3xx Status codes result in an instant redirect.  Specifying a Retry-After > 0 does not give the browser any pause as it should.

A 503 with a Retry-After does not result in a retry unless "Location" is also specified.  Again the Retry-After time is ignored.  If it is not present the redirect will still occur.

It seems to me that a 503, being a server error, should cause the client to resubmit the entire request to the same URI.  I can't find anywhere in the spec that says a 503 should ever have a Location header, let alone require one.

If you have access to a PHP server - a test could look like this (use bug230260.php?reset=1 to test, putting the reset=1 back in after each run):

bug230260.php

<?php
session_start();

if ($_REQUEST['reset']) {
  $_SESSION['test'] = 0;
  header('HTTP/1.1 307 Temporary Redirect');
  header('Location: '.$_SERVER['SCRIPT_NAME']);
  header('Retry-After: 4'); // Ignored
  session_write_close();
  echo 'Test has been Reset. Should wait 4 seconds.';
  exit;
}

if (empty($_SESSION['test'])) {
  header('HTTP/1.1 503 Temporarily Unavailable');
  header('Location: '.$_SERVER['SCRIPT_NAME']); // Shouldn't be used?
  header('Retry-After: 2'); // Is Ignored
  $_SESSION['test'] = 1;
  session_write_close();
  echo 'Sent 503 with retry after 2 seconds';
  exit;
} else {
  echo "And we're back.";
}
The PHP CMS Drupal has been setting this header since Drupal 6's ImageCache module (about 6 years ago). We set this header for dynamically generated images the are created on-demand based on the URL (for example a resized image that needs to be scaled down). I know WordPress has a similar mechanism that generates images on demand as well, though I don't think they try to use the "Retry-After" header.

Because image generation is an expensive operation, we throttle the number of requests that can generate an image and prevent two simultaneous requests from generating the same image twice. It would be great if browsers would respect this header when retrieving images, as it would let the server generate as many images as it could handle, then retry automatically to load the remaining images.


See https://api.drupal.org/api/drupal/modules!image!image.module/function/image_style_deliver/7 for example code where we set this header.
Whiteboard: [http/1.1] → [necko-backlog]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.

Severity: normal → S4
Priority: P3 → P5

I believe this bug should be handled for both easy of use on the user and also to easy on the server resources.
If the user tries to access before "retry-after", the browser should give a friendly reminder. Otherwise, the browser should try again on its own.

Flags: needinfo?(jstutte)
Severity: S4 → --
Flags: needinfo?(jstutte)
Priority: P5 → P3

We'll keep it closer on our radar, though P5 also does not mean closed, we are always happy to review patches in case!

Severity: -- → S4
You need to log in before you can comment on or make changes to this bug.