119494 - Acrobat fails to load document from this site [200 expecting 206]

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect, P1)

Description

[Frank Burleigh]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.7+)
Gecko/20020111
BuildID:    2002011103

Acrobat plugin starts but the PDF document does not load.  Moz appears to be
"busy" (mouse cursors don't change, browser window may not repaint, etc).  These
"busy" behaviors sometimes go away after several 10s of seconds.  Other open Moz
windows are functional.  The Acrobat plugin may report in IO error over the
network.  On the same machine, IE6/Acrobat work ok.



Reproducible: Always
Steps to Reproduce:
1. visit the url (you might also click and url and press enter again)
2. click out of the browser, or to another moz window, try to click back to the
original browser window.


Actual Results:  No PDF document on screen, usually a browser that appears
frozen for a period of time.  Clean Acrobat 5.05 win32 installs.

Expected Results:  PDF should load, browser should be responsive.

Behavior also observed on NS6.21 on XP (56k modem connection) and NS6.21 on NT
(ethernet connection).  In general we are not having PDF issues, but this is one
of two sites where we seem to have problems.

Comment 1

[shrirang khanzode]

yes, confirmed, marking NEW. Is this related to the byte stream problem, by any 
chance?

Comment 2

[Peter Lubczynski]

Anyone got a HTTP log they can attach? Headers should be enough.

Comment 3

[Frank Burleigh]

No, I don't even know how to create something like that.  Sorry... ;-)

Comment 4

[shrirang khanzode]

Attachment: Http log attached

Comment 5

[shrirang khanzode]

Attachment: log pertinent to pdf url reattached

Comment 6

[Peter Lubczynski]

Thanks for the log Shrirang!

Searching through the log, we make a "Range:" request. However, the response
back from the server looks like a "200" with the whole document. Kinda looks
familiar,  similar to another one we've seen recently in another bug with a
proxy cache, but this looks to be with Netscape HTTP 1.1 server.

Comment 7

[Doug Turner (:dougt)]

Darin, correct me if I am wrong, but the responses that you are seeing is from the
destination server.  You do not see the VIA which would indicate what kind of
proxy you are using.

Comment 8

[Darin Fisher]

any web server or web proxy is permitted to return 200 w/ the entire document to
a range request.  the user agent is expected to handle this case.

Comment 9

[lmcquarr]

Hi folks:
Just last week, Peter L and Doug T and I participated in a converation with the 
AOL server group about a similar problem.  Before this conversation, we explored 
if there was anyway to tell the plug-in from the browser AFTER the stream has 
been opened that the stream is NOT seekable afterall. 

I looked carefully through the plug-in interface and the Acrobat plug-in code
and concluded that:
1 - The legacy plug-in interace that we are all living with does not provide
a mechanism to tell the plug-in after the stream is open that it is NOT
seekable afterall. 
2 - And certainly, there is no provision in the shipping Acrobat code
to handle this case.  


We concluded that the only thing that the browser code could do to would
be to close the current stream and reopen it as **non**  seekable (in the case
that it is observed that the response to a byte range request is "200"
and not "206" -- partial content).   

Comment 10

[Doug Turner (:dougt)]

Liz, does reopening the stream after the plugin requests a range work?  I
remember that we had problems when we prematurely closed a range request stream.

Comment 11

[lmcquarr]

I *believe* if you close and reopen the stream, eveything should be fine.
The Acrobat plug-in code should handle being closed at any time, right?
Users can select BACK, or close the browser window, at any time, right?

If you want to hack together some test code, I could test it against this site
just to be completely satisfied that this is the case.

Just let me know ... (I haven't built the browser for a while so it would
be better to give me an .exe/dll if possible).

Comment 12

[Darin Fisher]

closing and reopening the stream sounds to me like the right solution.  it would
probably be good to remember the fact that certain domain's don't do byte range
requests; however, this is really tricky to get right, because servers are
allowed to respond to a byte range request with a 200 response whenever they
feel like it.  

you could have a server, for example, that is serving up some document that
changes frequently... say once every 5 minutes.  for a 5 minute interval byte
range requests would result in byte range responses (206's), but after 5 minutes
a byte range request would result in a full document 200 response.

this means that trying to remember the fact that a URL had trouble doing byte
range requests is probably not feasible.  we can redo requests on behalf of the
old plugin API as a work around solution, but performance will obviously suffer.

is there a more modern plugin API that would allow plugins to handle 200 when
they expect 206s?  is there any hope that adobe would rework their plugin
anytime soon?

Comment 13

[lmcquarr]

Hi Folks:

I got into the debugger in the Acrobat Netscape plug in and noticed
one thing that you can fix right away.  It seems that on this file
on this server (which claims that it supports ranges but really doesn't),
after Acrobat tells mozila (9.7) to do the first byte range request, which
the server responds with "200" and the entire file and not
"206" and the byte range,  mozilla  never calls us
back again with the data (NPP_Write).  In other words, Acrobat
never gets anymore data from mozilla at this point, even though the
entire file is downloaded.  (I tested 0.9.7 from build 200112210006).

I compare this to the behavior of Navigator 4.X in the same situation:
Even after Acrobat tells Nav to do the first range request, and
the server responds 200 and the entire file, Nav passes the data
on to Acrobat via NPP_Write.

So the first thing that we can do to fix this situation is to
have mozilla  do what Nav 4.X does: give us the data even
though that is not what we requested.

Having said that, there is still some work to do on the Acrobat
side to gracefully recover from this situation (Nav 4.X still shows
a blank screen ... even though it did get the data).   Honestly,
given the fact that this does NOT happen that often, I do not think
I can push for a bug fix until the next major Acrobat release, which is way,
out there ....   

Comment 14

[lmcquarr]

Hi Folks:

See my previous comments first.  I found the code in the
Acrobat Netscape plug-in that,  when removed, will allow
Nav 4.X to work correctly with this server and other servers
who  lie about supporting byte range requests. (The problematic
code in the Acrobat Netscape plug-in  was a bug work around
for a early Netscape server bug ... circa 1995. :-)

I will make a fix for the next major release of Acrobat (best
I can do at this point, since this is a relatively rare
bug).  Can you folks make sure that 
the data that is being downloaded is delivered to us? 

Comment 15

[Peter Lubczynski]

-->peterl

I'll take a look while Andrei is on vacation....

Comment 16

[Peter Lubczynski]

Nav 4.x with the plugin looks to have the same problem, but ONLY when the cache
is cleared. Reloading the page causes us to fetch the document from the cache so
no byte range requests happen. It doesn't look like we are trying to fetch the
document from the cache at all in Mozilla, but that may be another issue.

Comment 17

[Peter Lubczynski]

Attachment: reset plugin stream patch

Comment 18

[Peter Lubczynski]

Comment on attachment 66786 [details] [diff] [review]
reset plugin stream patch

This patch to Mozilla attempts to detect the condition where Necko doesn't give
us a byte range stream but the plugin is expecting it. I attempt to reset the
stream to a non-seekable one and keep handing off the data to the plugin. It
doesn't look like Acrobat likes this or it's expecting something else. It may
want it as a file but this patch isn't quite there yet.

Comment 19

[Peter Lubczynski]

nominating nsbeta1

Comment 20

[Peter Lubczynski]

Liz, I'm a bit stuck on this one.

I've traced through your code up to PDFXInstanceFileOpen, where a message is
dispatched, and nothing happens. The file is in on the disk, where we say it is
in StreamAsFile and it is valid if copied and opened later.

I made a slight change in the patch to send a network error code for closing the
stream instead of done.

Comment 21

[lmcquarr]

Can you send me the patch such that I do not have to build it?
If you can, I can take a look at it this morning.

Comment 22

[Winnie Lam]

nominating nsbeta1+ as per adt triage.  this happens on some servers, and
wouldn't want them to hang....

Comment 23

[Winnie Lam]

adding adt1 to status whiteboard as per discussion with beppe since this is a
rare occurrence and that compuserve has already addressed it.

Comment 24

[Peter Lubczynski]

-->serge

I think we may have to restart the whole plugin instance and ensure we don't go
down the byte range route. If we encounter this condition, maybe something like:
NPP_DestroyStream
NPP_Destroy
NPP_New
NPP_NewStream

Comment 25

[Frank Burleigh]

Here's another--and important for legal professionals and others--site showing
this problem.  Netcraft says the server is Netscape/4. The PDF opens quickly in
IE, but doesn't open at all in Moz, eventually dying with an IO error.

http://www.senate.gov/~durbin/Legislation/98-282.pdf

What does Winnie mean that "Compuserve has solved it?"

Thanks.

Comment 26

[serge (gone)]

http://www.senate.gov/~durbin/Legislation/98-282.pdf
WFM on w2k, mozilla 20020405, acrobat 5.0

Comment 27

[Frank Burleigh]

Serge: I've tried a few different things which I'll detail below.  In summary,
I've reproduced this behavior on three different machines.

My environment is XP, lan, moz 2002040803.  Acrobat is 5.05.  Moz was just
uninstalled and reinstalled today.  I visited the site again, got the same
timeout behavior.  Then I uninstalled acrobat and reinstalled, then visited the
site again.  The acrobat license prompt appeared, I agreed to it, and I beheld
the PDF appeared immediately.  I closed Moz then visited the site again--same
timeout behavior with the message from Reader being "A file I/O error has
ccurred.  The file connection times out."  As I write, Moz's throbber shows no
activity, and the status bar claims to be "starting the plugin for
applications/pdf."

On a win2000 machine with NS6.21, the browser simply says that the object can't
be found or the server has been instructed not to give it to me.  The
environment of the user who reported this to me this AM is NT, also on our lan,
NS6.21.  The PDF comes over fine with IE on all three machines.

Comment 28

[serge (gone)]

Frank, you are right http://www.senate.gov/~durbin/Legislation/98-282.pdf
is another test case for this bug, some time this server returns 200 on range 
request, and mozilla kills the stream.

Comment 29

[Frank Burleigh]

Serge: thanks for the check.  Is Other Bug 11499 the one you mean?  That bug is
marked verified/wfm and is about mail.

Comment 30

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 31

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 32

[serge (gone)]

Attachment: patch v1

this patch uses brr listener wrapper, and resetting the plugin instance
and telling it should eat stream as file if byte range fails.
please review

Comment 33

[Peter Lubczynski]

Comment on attachment 82293 [details] [diff] [review]
patch v1

r=peterl

Wow serge, it looks like this fixes the 200/206 problem. There is a little
hesitation but then I see the plugin come up as expected.

I confirm I see this working with pluginlog:
nsPluginHostImpl::InstatiateFullPagePlugin End mime=application/pdf, rv=0,
owner=30f9030,
url=http://www.law.ucla.edu/Library/ResearchTools/guides/GuideC1.pdf
NPP NewStream called: this=2f24530, npp=30a5c58, mime=application/pdf, seek=1,
type=2, return=0,
url=http://www.law.ucla.edu/Library/ResearchTools/guides/GuideC1.pdf
ng URL http://www.law.ucla.edu/Library/ResearchTools/guides/GuideC1.pdf :
804b0002
ns4xPluginInstance::Stop this=30a5c40
NPP DestroyStream called: this=2f24530, npp=30a5c58, reason=2, return=0,
url=http://www.law.ucla.edu/Library/ResearchTools/guides/GuideC1.pdf
NPP Destroy called: this=30a5c40, npp=30a5c58, return=0
ns4xPluginInstance::Start this=30a5c40
NPP New called: this=30a5c40, npp=30a5c58, mime=application/pdf, mode=2,
argc=0, return=0
ns4xPluginInstance::SetWindow (about to call it) this=30a5c40
NPP SetWindow called: this=30a5c40, [x=0,y=0,w=1023,h=482],
clip[t=0,b=482,l=0,r=1023], return=0
NPP NewStream called: this=2f24530, npp=30a5c58, mime=application/pdf, seek=0,
type=3, return=0,
url=http://www.law.ucla.edu/Library/ResearchTools/guides/GuideC1.pdf
NPP StreamAsFile called: this=2f24530, npp=30a5c58,
url=http://www.law.ucla.edu/Library/ResearchTools/guides/GuideC1.pdf,
file=C:\DOCUME~1\PETERL~1\LOCALS~1\TEMP\plugtmp\GuideC1.pdf

Comment 34

[serge (gone)]

Thanks Peter for reviewing this.
There suppose to be a little hesitation, the plugin instance is getting reset on
the middle of stream loading.

Comment 35

[serge (gone)]

Darin, would you sr= for the patch, please?

Comment 36

[Frank Burleigh]

I've come across some additional instances where the plugin seems to start but
then never displays data.  In an example just now using trunk 2002050807, I'm
left with just "transfering data from..." on the status line.  The PDF is:

ftp://ftp.javasoft.com/pub/jms/PPeitQT9984/jms_tutorial-1_3_1.pdf

Another recent case happens here (simple site registration required):
http://www.javalobby.org/members/codenotes/CodeNotes_for_J2EE.pdf

I feel fairly confident the second case is this bug but a little less so the
first case.

Comment 37

[Darin Fisher]

Comment on attachment 82293 [details] [diff] [review]
patch v1

>Index: nsPluginHostImpl.cpp

>+  nsresult ServeStreamAsFileWhenByteRangeRequestFailed(nsIRequest *request, nsISupports *ctxt,
>+                              nsresult status);

can you come up with a shorter name?  how about just ServeStreamAsFile()?

otherwise, this patch looks good to me.  sr=darin

Comment 38

[serge (gone)]

I'll change that name, thanks.

Comment 39

[serge (gone)]

checked into the trunk
mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp,v  <--  nsPluginHstImpl.cpp
new revision: 1.384; previous revision: 1.383

Comment 40

[Frank Burleigh]

Thanks, [e-mail].  We've kept a list of affected documents and will
test them out!  Question: is there a defined way to also apply trunk fixes to
future Mozilla RCs and future Netscapes?

Comment 41

[serge (gone)]

all mozilla releases are based on the trunk, so this patch will be automatically 
included into the next mozilla 1.0.1 release.

Comment 42

[Darin Fisher]

serge: that's incorrect... mozilla 1.0.1 will be based on mozilla 1.0.0, not the
trunk.  cc'ing asa in case i'm mistaken.

Comment 43

[Matthias Versen [:Matti]]

I'm not Asa but...

Darin is right. Mozill1.1 will have the fix, Mozilla1.01 will be base on the
current branch.
(see www.mozilla.org/roadmap or just this image :
http://www.mozilla.org/roadmap/branching-2002-05-01.png)

Comment 44

[serge (gone)]

o yeah, thanks for the correction.
 

Comment 45

[Frank Burleigh]

Hm.  That's what I thought, I think.  So that means rc2 won't have this fix. 
Ok, I understand.  Bur what gets this into the branch and into future Netscapes?
 That's the important thing in at least my local situation.

Comment 46

[serge (gone)]

I'll persuade to include this into the next netscapes rtm.

Comment 47

[Frank Burleigh]

serge: thank you, thank you very much.

Comment 48

[serge (gone)]

adt1.0.0

Comment 49

[serge (gone)]

*** Bug 143592 has been marked as a duplicate of this bug. ***

Comment 50

[scottputterman]

Let's get this verified on the trunk.

Comment 51

[Frank Burleigh]

I have tested the two cases shown here that I know to be about this issue, and
both now "work."  I believe my user has a few more cases we could test.  If you
were to get the patch into the rc2 branch I could update a few machines so
actual users could test this, too.

Marking verified.

Thanks!

Comment 52

[rubydoo123]

tested for RealPlayer8 and QuickTime on the trunk and they function as expected.
I can test Flash and Acrobat as well

Comment 53

[rubydoo123]

Just ran through the test suite on the adobe site, tests pass

Comment 54

[kysmith0 (gone)]

wfm on nt4.0 using trunk build 2002051408

Comment 55

[lmcquarr]

http://www.senate.gov/~durbin/Legislation/98-282.pdf
WFM on w2k, mozilla trunk 2002051408, acrobat 5.05
(and I verified that the server is still behaving incorrectly -- AWESOME!)

Comment 56

[Terri Preston]

Document loaded fine using win XP trunk build 2002051408

Comment 57

[serge (gone)]

AFAIK only adobe's acrobat & viewpoint plugins are using byte range request, so 
only these plugins could be affected by this patch.

Comment 58

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 82293 [details] [diff] [review]
patch v1

a=[e-mail] for branch checkin

Comment 59

[serge (gone)]

Checked in on MOZILLA_1_0_0_BRANCH
mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp,v  <--  
nsPluginHostImpl.cpp
new revision: 1.372.2.13; previous revision: 1.372.2.12
Thanks all.

Comment 60

[rubydoo123]

tested this on win98 using branch bits from 20020516 and I was able to
successfully view http://www.law.ucla.edu/Library/ResearchTools/guides/GuideC1.pdf

able to scroll through, click outside and set focus again, etc.

I also ran through Plug-in verification testing as well to ensure this check-in
did not affect other plug-ins.
http://mozilla.org/quality/smoketests/  3(o). Browser Plugins (optional)
-- all tests passed as expected

http://mozilla.org/quality/browser/front-end/testcases/plugins/
-- all test passed as expected

http://acroeng.adobe.com/BrowserTestSuite/
-- tests passed as expected

http://jazz/users/shrir/publish/flashacceptancesuite/
-- tests passed as expected

Plug-ins tested:
Acrobat 5.0
QuickTime 5.02
Flash 6.0 r23
Media Player 6.4
RealPlayer8
Shockwave 8.5
WinAmp 2.80

Comment 61

[jlbryan]

I installed Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0rc3) Gecko/20020519
to try some of the PDFs but am not having good luck.  The UCLA link loaded the
PDF the first time but all subsequent attempts show "document done" but Moz is
then dead (have to kill it in task manager) and the PDF never appears.  Is the
fix in my build?

Comment 62

[serge (gone)]

yes, fix is in Gecko/20020519 build.
could you be more specific  what did you do after opened this url
http://www.law.ucla.edu/Library/ResearchTools/guides/GuideC1.pdf

Comment 63

[Frank Burleigh]

Chri/Serge:

i've just been down to the machine.  some points:

- procedure earlier when we saw this problem again was this: install moz, visit
page (PDF showed), back button--that froze mozilla, task list said "not
responding."  i tested this a few times with the same result.  that's why we
reopened the bug.

but...

- we are now able to open the document fine, no problem.  we've cleared the
cache, closed moz, reopened, tested, used the back button, opened again and even
again.  i believe acroread on that machine tends to get "stuck" open.  sometimes
when i visit the machine there is no acro window, no browser is open, yet
acroread is still in the task list.  maybe we ran into this earlier?

we will do some further testing, see how it holds up through the day then do the
right thing with the bug status.

- i don't think talkback is in mozilla-win32-installer-sea.exe; the network
installer (mozilla-win32-installer.exe) is still broken--can you ask them to
test and fix that so we can get talkback involved here?  this has been a problem
since friday i'd guess.

Comment 64

[serge (gone)]

there is a possibility when Acrobat.exe process runs into a bad stage and 
stucks, in which case nppdf.dll plugin is unable to communicate with Acrobat.exe 
and it'll hang browser's process ( mozilla or netscape 4.x) 
a workaround I know of is kill the browser's & Acrobat.exe processes:(

Comment 65

[Peter Jenkins]

http://www.senate.gov/~durbin/Legislation/98-282.pdf
WFM, Windows XP Pro, Nightly Build 2002051910, Acrobat 5.0

Comment 66

[rubydoo123]

I'm a little lost on why this was reopened. If the page loads, then this is
fixed. If you lose navigation, that would be another bug. If you suspect that
Acrobat is failing, that would also be another bug.

Testing this on the branch using a build from 20020520 on win98 works fine.
Multiple reloads works as expected. The document does take time to load (~5-8
seconds).

Comment 67

[Mike Kaply [:mkaply]]

> we are now able to open the document fine, no problem.  we've cleared the
> cache, closed moz, reopened, tested, used the back button, opened again
> and even again.  i believe acroread on that machine tends to get "stuck" open. 
> sometimes when i visit the machine there is no acro window, no browser is
> open, yet acroread is still in the task list.  maybe we ran into
> this earlier?

This is how Acrobat works. When you load a PDF document, it starts the acrord32 
process in the background to communicate with the plugin. That process stays 
running when the browser is closed. It works this way on 4.x and Mozilla.

Comment 68

[rubydoo123]

meant to mark fixed in previous submit

Comment 69

[Jaime Rodriguez, Jr.]

Is this really fixed on the branch and the trunk? 

Shrir - Can you verify this?

Comment 70

[shrirang khanzode]

verified on 98 and 2k this is fixed on branch 0521.

Comment 71

[wongqc]

It seems fixed on 1.0 RC3 (Build 2002052306). However, it still does not show
the progress correctly when downloading a huge pdf.

http://www.novell.com/products/edirectory/competitive/ad.pdf 
(around 800k)

It does load, however during downloading, the status bar at the bottom shows
"Document Done". The mozilla icon also does not spin to show it's downloading.
Only indication of activity is my network status blinking, until it finally
finished downloading and show up inside the browser.

Nothing critical, just minor cosmetic stuff. 
Otherwise it opens all my pdf correctly. =)

Comment 72

[lmcquarr]

Regarding the previous comments, Adobe QE Jeff Moran also observed the
lack of progress.  I entered a new (non critical) bug: 146748.

Comment 73

[Frank Burleigh]

NS 7 PR1 does not appear to include this fix.  PR1 installed to win2000, Acrobat
5.05 reinstalled and tested.  The problematic URLs listed in this bug do not
open and, once tested, the browser was unresponsive.

Comment 74

[serge (gone)]

Help->About Netscape
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020516
Netscape/7.0b1.
all netscape binaries with  build number more than 20020516 have this patch in. 

Comment 75

[shrirang khanzode]

ucls testcase is no longer there. However, tested  this one:
http://www.senate.gov/~durbin/Legislation/98-282.pdf

works great on trunk 0812.