Skip to Content

HTTP Accept-Ranges support improved

I thought I'd blog about this, hoping some web developers may find it useful.

Previously, Mozilla's HTTP protocol implementation did not check the presence of the Accept-Ranges response header.  The job of this header is to tell the client whether it can perform HTTP range requests, and if so, in what units should it express its range requests.  Practically, the only unit used by web servers is bytes, so this header's job in the real world is to tell the server whether it can perform range requests at all.

The main purpose of performing range requests is either supporting download resume (where you close the connection, and next time you request the resource, you specify the remaining range of the file in your HTTP request) or downloading files in smaller chunks simultaneously like download manager applications do (where they perform several range requests side by side in order to start downloading on multiple channels instead of a single channel).

Bad news was that the Accept-Ranges header was not checked in Mozilla at all.  So, if a server would send the Accept-Ranges: none response header, in order to tell the client that the download is not resumable, Mozilla was not aware of this fact, and would show the download as resumable to the user.  And this is bad, because for example a user might have such a download in progress, and when closing Firefox, it wouldn't prompt the user about the in-progress download, because it would blindly think that it's actually resumable, so it would pause the download hoping to resume it next time Firefox starts, but that of course didn't work.

In an IRC discussion with biesi, we noted the bug, so I filed and fixed bug 462707, which will appear in Firefox 3.1 and later versions.  This makes Mozilla a little bit more conformant to the HTTP specification. 

Trackback URL for this post:

http://ehsanakhgari.org/trackback/88

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I got the same issue with FF,

I got the same issue with FF, sometimes after closing the browser with downoading progress i could not start it again because server didn't support furhter downloading after connection close. Now I see what was the issue, thank you very much for this bugfix

Regards,
nemo

Re: I got the same issue with FF,

I'm glad to hear that your problem has been fixed! 

Accept-Range & range request support

Is it really required to check Accept-Ranges field?
If Range request is supported, server sends Contents-Range field. So, client can depend on it. What is your opinion?

Also, if we make use of Accept-Ranges field, what should be behaviour in the following cases
"Accept-Ranges:",
"Accept-Ranges:abc" <-- Some invalid characters.

Re: Accept-Range & range request support

According to the HTTP spec, if a server does not send Accept-Ranges, then the client can assume that range transfers are available.  If the server sends Accept-Ranges: none, then the client should not attempt to issue range requests.  This is what we implemented and what my blog post was concerned with.

The Accept-Ranges: header alone is invalid and may be ignored.  The Accept-Ranges: abc header specifies that range requests are available in abc units (instead of bytes).  Since probably no HTTP client knows what an abc unit is, then it would again be safe to ignore this header as well.

> The Accept-Ranges: header

> The Accept-Ranges: header alone is invalid and may be ignored.
Does this mean that client can assume that server supports byte ranges and send range requests.

> "Accept-Ranges:abc
Does this mean that client can assume that server supports byte ranges and send range requests.

Re: > The Accept-Ranges: header

The answer to both questions is yes.

Accept-Ranges Vs Content-Range

Does Mozilla make use of both Accept Ranges and Content Ranges fields?

Accept-Ranges Vs Content-Range

Yes, Content-Range determines which part of the content is being served on the current connection.

HTTP specification compliance

“This makes Mozilla a little bit more conformant to the HTTP specification.”

Great :).

Maybe it would be nice to make an effort to just go through all HTTP-related bugs and the entire HTTP specification to find places where Firefox is not following the HTTP protocol or not using certain HTTP headers that were provided, to get HTTP support really up to a perfect level.

E.g. for example I’m thinking about the caching implementation (the Vary header is not respected - bug 388141, and I think I read somewhere that a POST/PUT/DELETE to a URL does not clear the cache), or showing a bookmark update info bar (like the remember password bar) in response to a 301 Moved Permanently response, providing a log-out button for web pages using HTTP authentication, maybe show/do something useful for 204 No Content responses (and when it contains a Location header, does it redirect you there?), etc…

Re: HTTP specification compliance

It would be great if you can report a bug for any such non-compliances that you see in Mozilla's HTTP implementation, so that developers can take a look on fixing them.  Thanks!

Re: HTTP specification compliance

I do when I encounter them, of course. Was just suggesting to make a reading, testing and fixing effort, basically.

Good to see this fixed

Nice! We just recently added the ability to resume downloads in TomTom HOME (this was released last week) and we had to add an explicit check for Accept-Ranges - just so we don't try to resume with servers that don't support it. Now that exactly the same check was added to XULRunner we will be able to remove our check.

Re: Good to see this fixed

I'm glad to know that this fix was useful for you.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.
CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.