528807 - HTTP 206 responses from Microsoft IIS 7.5 sometimes not parsed correctly

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect)

Description

[Rudi Sherry]

Firefox's plug-in host does not properly parse one legal variant of HTTP 206 Partial Response.  I don't know if this is a plug-in issue or a Core issue.

Method:

(1) Install Adobe Reader 9.2
(2) In Firefox, empty the cache
(3) In Firefox, go to http://www.cui.com/pdffiles/nsa.pdf

(BTW, this has nothing to do with the NSA, it's a hardware supplier).

Result:

Several requests will go to cui.com; the first a full GET for the URL (from Firefox), the second a byte-range GET request (from Reader, through Firefox).  The response to the first is HTTP 200, then the response to the second is HTTP 206 with a single range.

This second response is never transmitted to Reader through the NPAPI "NPP_Write" call, and that's the bug.

BACKGROUND:

According to RFC 2616 section 10.2.7, a response to a byte-range request with multiple ranges can take one of two forms.

See <http://tools.ietf.org/html/rfc2616#section-10.2.7>
and <http://tools.ietf.org/html/rfc2616#section-14.16>

The most common form is a response with Content Type multipart/byte-ranges (or multipart/x-byte-ranges) and then a set of parts.  Firefox parses this correctly.

A different form, allowable if either there is one single range or all the ranges can be coalesced into a single range, is a response where the Content-Type and Content-Range are in the HTTP headers, and there are no parts; there is only the range's contents as the body.

When this reply comes back, Firefox does not transmit it to the plug-in via NPP_Write.

WHY IS THIS COMING UP NOW?

Microsoft's IIS server version 7.5 now returns this form for ranges that can be coalesced, and that is new with this version (I have confirmed that with Microsoft). The URL above is one example of that.  Presumably IIS 7.5 will slowly be rolled out in more and more locations.

Comment 1

[Rudi Sherry]

If you don't see the second request, you may need a slower connection; if the connection to that server is too fast the entire file will come down in the first request before Reader decides to ask for more.  Either use a throttling proxy, or have a PDF already opened in a separate window so Reader is pre-loaded before getting this PDF.

Comment 2

[Benjamin Smedberg]

Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.