286853 - Doing NPN_RequestRead on some HTTP and HTTPS servers results in the destruction of the stream

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect)

Description

[salil kapoor]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; digit_may2002; SV1; .NET CLR 1.1.4322)
Build Identifier: mozilla/5.0

If I try to download a PDF file from a server using NPN_RequestRead, mozilla 
returns NPP_DestroyStream and then opens a new stream for the same URL but 
does not give us a window to display it in.

Reproducible: Sometimes

Steps to Reproduce:
1. I am attaching a dummy plugin. Dowload and install it on mozilla (Linux)
2. Now try to access a PDF file on http://www.massvacation.com
3. Observe the messages in /tmp/nppdfmessages

Actual Results:  
The browser started the autodownload wnd returned the data in NPP_Write. But 
as soon as we do a NPN_RequestRead, the browser gives a call to 
NPP_DestroyStream and then to NPP_NewStream with seekable turned off, and then 
downloads the entire file again for us. But does not give a window through 
NPP_SetWindow for this new stream.

Expected Results:  
The stream should not be destroyed and the NPN_RequestRead should work 
correctly.

Comment 1

[salil kapoor]

Attachment: A dummy plugin to show the described bug behaviour.

Comment 2

[salil kapoor]

No response on this bug ?? Really surprising. No one there to help me out.

Comment 3

[Rudi Sherry]

(In reply to comment #0)
> If I try to download a PDF file from a server using NPN_RequestRead, mozilla 
> returns NPP_DestroyStream and then opens a new stream for the same URL but 
> does not give us a window to display it in.
> 
> Reproducible: Sometimes

I am familiar with Salil's environment.  I believe this could be happening because a bad 206 Partial 
Content response is being generated by the proxy server for the GET request made by Firefox for the 
NPN_RequestRead range (although I'm not positive about that).  Here is the comment I added to another 
bug he entered, 286546:

---------------------
I researched this and found the double delimiter is (incorrectly) added to the 206 response by the  
BlueCoat proxy software (SG version 3.2.4.x).  BlueCoat is one of the leading vendors of firewall  
software in the US so can affect many medium and large businesses.  Anyone not using this proxy will  
not see this double delimiter.  BlueCoat is aware of this problem and I assume they are addressing it.

The double delimiter is the only problem with the 206 response -- if you ignore it, the response is 
complete and correct.  I believe Mozilla should handle this pathological case to avoid this problem for 
businesses that are using that particular BlueCoat version.  I am willing to test it if necessary, since not 
everyone has access to BlueCoat's software.

I am adding this same comment to 286853, since I believe it's the same problem.  I'm not as familiar  
with the bug-reporting process so I'll leave it to others to change the status or close one of the two 
bugs.
----------------

Comment 4

[salil kapoor]

I've been doing a lot of research on this bug and it turns out that the proxy 
server is not causing any problems in this scenario. Here when we do a partial 
content request, the stream is being destroyed by the source itself and a new 
stream is being created, which is marked as not sreamable. However, the 
browser does not do the cleanup process totally, and tries to reuse the X 
window of the previous stream, however that window is no longer valid because 
of the destruction of the window in one of the functions.

Comment 5

[aravindm]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.4) Gecko/20100413 Firefox/3.6.4
Please update if you are able to still reproduce with the latest nightly build  ftp://ftp.mozilla.org/pub/firefox/nightly/latest-trunk/

Comment 6

[Ed Morley [:emorley]]

Closing since now after whiteboard closeme date and no reply to last comment.

Please reopen/comment with further info, if you still see this issue with Firefox 3.6.13 or later, with a clean profile and the latest version of the plugin.

If you wish, you can also try to reproduce in Firefox 4 Beta 8 or later:
http://www.mozilla.com/en-US/firefox/all-beta.html