RE: Apache Group

 An argument is only as good as its assumptions.

1. MSIE does not implement NPN_RequestRead().
2. Adobe gets range support through an ActiveX control originally
written by Microsoft. However the code is public domain and to the best
of my knowledge never has and never will ship in any Microsoft product.
Thus the only people who can change Adobe's PDF viewer behavior is
Adobe.

BTW I would like to make it absolutely clear that Adobe has done nothing
wrong or even questionable. Their PDF viewer supported the most advanced
multiple read range mechanism available at the time.

		Yaron

PS It is just a guess but I suspect that Adobe's cache behavior occurs
because they are calling the WinInet cache API which allows programs to
place files directly into the cache.


>-----Original Message-----
>From:	Alexei Kosut [SMTP:akosut@nueva.pvt.k12.ca.us]
>Sent:	Wednesday, February 19, 1997 7:35 PM
>To:	Yaron Goland
>Cc:	Thomas Reardon; Joe Peterson; Rajeev Dujari; Richard Firth; 'Henrik
>Frystyk Nielsen'; 'http-wg@cuckoo.hpl.hp.com'
>Subject:	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 Thursday, 20 February 1997 23:06:46 UTC