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.