230260 - Retry-After sent with HTTP 503 response is ignored

Status: NEW

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

Description

[boozai]

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!

Comment 1

[timeless]

we have an atom for it, but no consumers...

Comment 2

[Darin Fisher]

interesting, ok.  is there a spec somewhere for this field?

Comment 3

[Darin Fisher]

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.

Comment 4

[David Nesting]

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?

Comment 5

[Darin Fisher]

Yes, that sounds like a good idea.

Comment 6

[Marques Johansson]

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.";
}

Comment 7

[Nate Haug]

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.

Comment 8

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 9

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 10

[Jens Stutte [:jstutte]]

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.

Comment 11

[brunoais]

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.

Comment 12

[Jens Stutte [:jstutte]]

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