RE: Apache Group

On Wed, 19 Feb 1997, Yaron Goland wrote:

> MSIE 3.x does not and MSIE 4 will not make multipart byte-range
> requests, thus there is nothing to fix in MSIE.

This is true for the basic MSIE product, yes. However...

> It is true that products that interact w/MSIE, like Adobe's PDF plug in,
> do use multipart byte-ranges. We have no control over third party
> software as we do not implement support for byte-ranges in any of our
> software. The best we can do is provide advise. When Adobe built its
> plug-in, we advised them to use multipart/x-byterange because that was
> the most advanced spec at the time. We now advise those who ask to use
> multipart/byterange.

I am willing to be wrong, but that is not my understanding. The
Netscape plug-in spec (as specified at
http://home.netscape.com/eng/mozilla/2.0/handbook/plugins/index.html)
defines a few methods in its API that I assume are used by a plugin
such as the PDF one: NPN_GetURL(), which opens a stream given a URL,
and NPN_RequestRead(), which "requests a range of bytes... from a
seekable stream", and is given a list of ranges as an
argument. Nowhere does the plugin specify exactly how this request is
to be made, nor does it directly interpret the response.

In other words, my understanding is that the plugin simply calls the
API functions that say "I want these ranges from this URL", and the
browser goes out and gets it for it, however the browser wants.

Even not knowing the plugin spec, this is the only way to explain
certain phenomenon I have observed with plugins:

1. They read cached documents. If I go to a PDF file, then go back to
it, I get the version in my cache. If the plugin was actually
responsible for going out on the wire and getting the file, this would
not be happening (I find it doubtful that the plugin makers know the
innards of each browser's caching mechanisms). In addition, everything
about a request made internal to a plugin (like the getting of parts
of a PDF file) is completely consistent (across all the browsers I
have used) with that browser's normal handling of HTTP transactions;
something that would not likely be true if the plugin was handling the
request or response.

2. The behavior of an *identical* plugin file differs from browser to
browser in terms of what's sent over the wire. For example, Netscape
Navigator sends a Request-Range header as well as a Range header (with
identical content). MSIE does not (it only sends Range). If the plugin
were responsible for requesting and parsing a range, surely the
headers would be the same?

And if it's not the browser's domain, then why have we been told by
(for example) folks at Netscape that they've changed it for the next
release of Navigator 4.0? The information I've recieved from people at
Adobe is equally indicative that it is the browser responsible for
protocol issues of this sort, not the plugin.

Of course, I'm quite willing to concede that I am wrong here, but this
is my understanding.

> If there are any other questions or concerns on the issue of Microsoft
> and byte-ranges, I am the proper person to speak with.

Thanks!

-- 
________________________________________________________________________
Alexei Kosut <akosut@nueva.pvt.k12.ca.us>      The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/   http://www.apache.org/

Received on Wednesday, 19 February 1997 19:40:09 UTC