54689 - Blank page loads when trying to access pdf on a secure server

Status: VERIFIED FIXED

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

Description

[shrirang khanzode]

build: windows branch bits 20000928.
This test is from the adobe testsuite.

Steps to reproduce :
1 Launch seamonkey
2 Click on the url given above
3 Observe that nothing loads and a blank page appears in the browser window

Expected: Pdf file should load in the browser window.

This page loads fine in 4.72 browser.

Comment 1

[av (gone)]

I see 'The connection was refused when attempting to contact junruh.mcom.com' 
dialog. 

Comment 2

[ekrock's old account (dead)]

Not a Netscape 6 RTM blocker. FUTURE. This bug has been marked Future because
the Netscape engineer it is assigned to is overburdened.

Comment 3

[shrirang khanzode]

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

Comment 4

[Bob Clary [:bc] (inactive)]

This bug is critical for anyone who needs to distribute or receive documents
securely. This affects financial institutions as well as online investment firms
and their clients.

Changing target to mozilla0.9.

Comment 5

[av (gone)]

I cannot reach any https: site to what happens here. Assume some problems with 
security should be fixed (first).

Over to Security.

Comment 6

[Mitchell Stoltz (not reading bugmail)]

Please assign SSL-related bugs to Security:Crypto. Reassigning.

Comment 7

[Asa Dotzler [:asa]]

Unsetting Target Milestone, adding nomination keyword.  Nominating is done with
Keywords, not Target Milestone.  Target Milestone is used by the developer to
communicate the development cycle in which he intends to fix the problem.

Comment 8

[Peter Lubczynski]

I bet this is happening on all platform too, not sure. How important is this? I 
nominate for mozilla 0.9.1

Comment 9

[Bob Lord]

This works for me with the latest builds (with PSM 2.0).  Please re-open if this
is still broken for you.

Comment 10

[shrirang khanzode]

where do I install  psm 2.0 from ? Thnx!

Comment 11

[shrirang khanzode]

Confirmed with Junruh, that this is still not working using today's commercial 
build on windows(0430). John, pls cehck with Bob when you visit him today. 
reopening...

Comment 12

[Arun Ranganathan]

Nominating nsbeta1 (it would appear that PSM 2 has some fixes on the way for
this bug).  It is critical to several people.

Comment 13

[shrirang khanzode]

john, any update on this one?  Thx

Comment 14

[Bob Lord]

John can you run test cases on WinME, WinNT, and Linux and see if you can 
isolate the test case?

I can confirm that this does not work for me on today's Mozilla build on WinNT.

Setting target to 2.0.

Comment 15

[shrirang khanzode]

2.0 ? Isn't this an 'important' bug and on our "Must Fix" list for Adobe ?

Comment 16

[John Unruh]

This bug is present in at least WinNT, Win98 and Win95. WinME is untested. Mac 
and Linux work OK.

Comment 17

[shrirang khanzode]

how is this working on linux for you? acrobat does not launch as a plugin at all 
on linux and if I try to load this secure document using acrobat as a helper 
app, I get a message "this document can be opened from inside the browser only". 
Checking on mac...

Comment 18

[shrirang khanzode]

pls ignore my comment about linux..the pdf does_open_up as a helper app  on 
linux 0503. There is another bug filed for "Acrobat not working as a plugin on 
linux". 

Comment 19

[John Unruh]

Mac testing with shrirang present - Acrobat will open a secure pdf file as a 
helper app, but when used as a plugin, a secure pdf file will not display.

Comment 20

[Peter Lubczynski]

I'm changing platform back to ALL as it's clear from testing, HTTPS links only 
work outside of the browser. Adobe expects them to work inside as in IE and Nav 
4.x.

Comment 21

[Peter Lubczynski]

Note: bug 78741 may be preventing accurate testing of this.

Comment 22

[Arun Ranganathan]

I can confirm that this one is pretty important to a great many users.  Does the
PSM 2.0 release coincide with 0.9.1 etc.?

Comment 23

[Mike Kaply [:mkaply]]

Can someone from the crypto team at least explain what the issue is here?

Comment 24

[John Unruh]

The issue is that opening a *.pdf file on a http:// web site works, whereas 
opening a *.pdf file on a https:// web site opens a blank window.

Comment 25

[Peter Lubczynski]

How can I verify I have PSM built on my win32 machine. Is it built by default?

Seem like when i tried the url above, I got an endless loop of ASSERTIONs. 
Here's the stack:
NTDLL! DbgBreakPoint@0 address 0x77f9eea9
nsDebug::Break(const char * 0x01a1ffe8, int 364) line 366
nsDebug::Assertion(const char * 0x01a2002c, const char * 0x01a20028, const char 
* 0x01a1ffe8, int 364) line 290 + 13 bytes
nsUnknownDecoder::FireListenerNotifications(nsIRequest * 0x03770fb8, nsISupports 
* 0x00000000) line 364 + 35 bytes
nsUnknownDecoder::OnStopRequest(nsUnknownDecoder * const 0x0345b9d8, nsIRequest 
* 0x03770fb8, nsISupports * 0x00000000, unsigned int 2152398899) line 225 + 16 
bytes
nsDocumentOpenInfo::OnStopRequest(nsDocumentOpenInfo * const 0x03770778, 
nsIRequest * 0x03770fb8, nsISupports * 0x00000000, unsigned int 2152398899) line 
255
XPTC_InvokeByIndex(nsISupports * 0x03770778, unsigned int 4, unsigned int 3, 
nsXPTCVariant * 0x034009a0) line 139
EventHandler(PLEvent * 0x03400948) line 509 + 41 bytes
PL_HandleEvent(PLEvent * 0x03400948) line 588 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00d786e0) line 518 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x002605de, unsigned int 49410, unsigned int 0, 
long 14124768) line 1069 + 9 bytes
USER32! UserCallWinProc@20 + 24 bytes
USER32! DispatchMessageWorker@8 + 244 bytes
USER32! DispatchMessageA@4 + 11 bytes
nsAppShell::Run(nsAppShell * const 0x00e29760) line 108
nsAppShellService::Run(nsAppShellService * const 0x00e2ae28) line 418
main1(int 3, char * * 0x00357f88, nsISupports * 0x00000000) line 1010 + 32 bytes
main(int 3, char * * 0x00357f88) line 1308 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! BaseProcessStart@4 + 115547 bytes

Comment 26

[Mike Kaply [:mkaply]]

Actually I was hoping more for something from the PSM team as to why this 
fails. Maybe if we could find out what actually the technical problem is.

Here is a better testcase:

Go to:

http://www.nasire.org/hotissues/justice/

Scroll down. click on:

Governance Models - Draft Report [158KB PDF]

The plugin loads, but the file doesn't come up.

As far as PSM 2 goes, it IS built by default on Windows and this problem still 
happens.

Comment 27

[Mike Kaply [:mkaply]]

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

Comment 28

[Mike Kaply [:mkaply]]

Argh

https://www.nasire.org/hotissues/justice/

This page is available BOTH secure and nonsecure.

If you use the https version which I put in, you do see the problem loading the 
PDF file from a secure link.

Comment 29

[Arun Ranganathan]

it would be a win of gargantuan proportions if this made it in by 0.9.1 time
frame (for obvious reasons).  certain parties are extremely interested in the
fate of this one ...

Comment 30

[Peter Lubczynski]

Just spoke with DougT and this is not a PSM problem. Necko does not cache https 
transfers so there won't be a file there for Acrobat to pick up. Doug suggested 
having the plugin code do the temporary file management as is done in Necko.

Reassigning to myself. Attempting to move to "plugins"

PDT, do you feel this is a beta stopper?

Comment 31

[Arun Ranganathan]

i hate to do this, but i didn't mark this bug originally as a beta stopper
because i was led to believe that it was fixed (psm 2.0).  chrisn believes this
is beta stopper material -- cc'ing chrisn and marek.  phil, if you & pdt
approve, could you change the target milestone?

Comment 32

[Phil Peterson]

I can't connect to either https://junruh.mcom.com or https://www.nasire.org

My opinion is that if this worked in 6.0, and doesn't work now, I'd pursue a fix
for 0.9.1 *after* the byte range bug and the Macromedia crashes. If it didn't
work in 6.0, I'd push to 0.9.2.

Comment 33

[Arun Ranganathan]

nope, did not work on 6.0.
unless chrisn jumps in based on the reasons i raised in the e-mail to everyone
concerned, i agree with phil.

Comment 34

[Doug Turner (:dougt)]

All, https is not cached.  Plugin's requires that disk cache is enabled.  

For this to work is that the plugin code must handle file downloading (writing 
to disk) if it want to support an OnFileAvail callback with either the HTTPS 
protocol, or if disk cache is disabled.

Comment 35

[shrirang khanzode]

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

Comment 36

[Peter Lubczynski]

Attachment: 6.0 trace with embedded https document

Comment 37

[Peter Lubczynski]

Attachment: 4.0 trace with https document

Comment 38

[Peter Lubczynski]

As is apparent from the attached traces, we were writing out https delivered 
bits to the local disk....eeek! 

Liz, will Acrobat work with just NP_WRITE calls vs. using a file? It's kind of 
bad to write securly delivered bits to a magnetic disk. If so, I can probably 
just convert NP_ASFILE streams to NP_NORMAL ones for https as a test.

If not, a cache like Dougt proposed needs to be made.

Comment 39

[Peter Lubczynski]

Oh, btw, to build PSM 2.0 on Windows you need to set BUILD_PSM2=1

Comment 40

[Mike Kaply [:mkaply]]

Why is this any different than when you get a PDF document from a secure server 
to use as a helper app? It is cached to disk then.

I can picture cases where people might be sending very large things via http 
servers - the idea that they can't ever be written to disk might cause some 
memory problems...

Comment 41

[home]

Just to clarify the security requirments in this case, it is just to discourage 
3rd party snooping of traffic. The end user storing stuff on their machine is 
not such a concern. The machines are all in private homes. It's a chrarity 
extranet.

Comment 42

[Phil Peterson]

Note that all previous versions of mozilla and Netscape don't write data
retrieved over https into the disk cache. I want PDF documents loaded over https
to work, but would like mstolz's opinion about the security ramifications.
cc'ing him

Comment 43

[Doug Turner (:dougt)]

Mike, the difference is that the helper application code handles the reading 
from the secure stream and writing to disk. The plugin code 
(modules/plugin/nglsrc) relies on the fact that it can pull local files from the 
necko cache.  I really don't think it is a good idea to put non-persistant files 
 in the disk cache.  This is why the plugin code has to write the stream to disk 
like the helper application code does.

Comment 44

[Doug Turner (:dougt)]

note, that the right person to review putting secure documents into the necko 
cache is david drinan.  I am sure that he would agree that this is a bad idea.

Comment 45

[lmcquarr]

In response to Peter's Q:  when you have the Acrobat plug-in installed,
using just NPP_Write calls to deliver the data to Acrobat is not
only OK, that is what we expect.  It doesn't matter if the data
is secure or not. 

When Acrobat is installed as a helper app, the browser writes the data
to a temp file and Acrobat opens that. 

Comment 46

[lmcquarr]

Peter --


Yikes -- unfortunately, the Acrobat plug-in is telling mozilla that
we want the data as a file due to a bug work around that we put
in.  Here are the details (open NP_PDFX.cpp in
the project and look for "httpshack" or read below):





                NPN_Version(&pmjr, &pmnr, &nmgr, &nmnr);


                /* **ER - Hack to workaround PR#308636.  See bug report for full 
details.
                   Basically, with Netscape 4.x, they refuse to cache HTTPS 
files (unless
                   requested by a plug-in) on disk, but will cache them in 
memory if they
                   are small enough.  If part of the file (for the initial read) 
gets cached
                   in memory, and we make a range request, the range request 
will fail because
                   they decide that it can be served from the cache, even though 
it cannot.
                   Yucky - read the bug report.  Anyhow, we try to detect this 
condition (using
                   hardcoded guess at memory cache size - don't want to dig 
through their prefs
                   file), and in this case we'll ask NS just to download the 
file to their
                   cache and give us the filename.  Because of the backdoor that 
lets files
                   from HTTPS that are requested by plug-ins be cached, this 
will work.
                   We don't need this hack if the stream isn't seekable (no 
byteserving, thus
                   no range requests).  If the server doesn't pass back a 
content-length,
                   stream->end is 0, so we aren't going to freak out.  This hack 
makes things
                   less efficient, as any HTTPS file <= 1 megabyte gets 
downloaded entirely,
                   but that's better than not working at all.  However, if 
Netscape's bug
                   gets fixed in a future version, we should bound the use of 
this hack only
                   to relevant versions.
                */
                DoHTTPSHack = ( seekable && ( nmnr > 10 ) &&
                        ( strnicmp( (char*)stream->url, "https:/", 7 ) == 0 ) &&
                        ( stream->end <= DEFAULT_MEM_CACHE_SIZE ) );



                /* Do we want to ask Netscape to download the file to its cache 
and give us the
                   filename to open directly, or to let us use a seekable 
stream? */
                if ( !seekable || DoLocalFileHack || DoHTTPSHack )
                {
                        /* Ask Netscape to download the file to the cache and 
give us the filename
                           to open from */
                        *stype = NP_ASFILE;
                        stream->pdata = s;
                        s->mode = PDFX_STREAM_ASFILE;
                }






**************************************************************************** 
*****


The DoHTTPSHack is set to true because:


The stream is seekable and the nmnr is 12 (greater than 10), and
the other conditions also exist.



OK -- What to do?    For some future version of Acrobat, I can change
that code to make sure it applies to the Netscape 4.X product only
by looking at the other variable that NPN_Version returns.  I will
check with management to see if they would allow such a simple
fix to be in the patch release that is under development.



On your side, you could change what mozilla returns in NPN_Version
so that the nmnr is 10 or less.  I don't know if this is a good idea
since other folks may be writing code to key off of this.  OR, you
could modify mozilla so that it allowed HTTPS files to be written
to a temp file, since that is the behavior of 4.X, which you are emulating.


While you are thinking about this, I will check with my management.


Liz

Comment 47

[lmcquarr]

I took at NPN_Version and what it returns in Netscape 4.77 versus Mozilla,
to see if I could bound our HTTPS hack bug work around (see above):

                  Moz                  Nav 4.77

Plugin major      0                    0
Plugin minor      11                   11
Netscape major    0                    0
Netscape minor    11                   12

We can, therefore, only put a bounds on our hack if the Nav 4.X product
line will never exceed 11 for Netscape minor (or they fix the bug
we were trying to work around).    Since Netscape minor has been
11 for quite a while, it may be safe to assume this (do you know
anyone in the sustaining engineering group for 4.X?  Marek was the last 
person I knew, but apparently he is now working on mozilla, right?)

Comment 48

[Brian Nesse (gone)]

I'm guessing that that last line should read:
Netscape minor    12                   11

The version was bumped to 12 for mozilla development when support for some new
values were added. It is a safe bet that no structural changes will be made to
the plugin support in 4.x so the version won't be changing again.

Comment 49

[Peter Lubczynski]

Liz, what do you need us to do on our side? How can we test? Even though no 
milestone is set, "they" would really like this for beta.

Comment 50

[lmcquarr]

Hi folks:

I am going to be able to put a bounds in for that bug workaround for 
our patch release for Acrobat 5.  Customers who experience this bug
should be able to therefore upgrade to the patch release. 

I would therefore make the priority of this bug MUCH LESS than
getting the DDE support (WWW_OpenURL working with Acrobat), as
well as any fixes to byte range support, which I am going to start
testing right now (hopefully all will be fine ... BUT...). 

Comment 51

[Mike Kaply [:mkaply]]

On OS/2, the only Acrobat Reader we have is 3.0 and we have this problem. We 
can't get Adobe to fix this. (If we could, I have a few other things that need 
fixing :)

Anyway, I was hoping the fix would be in Mozilla so that it would go into the 
OS/2 version.

I don't think hacking around this in Acrobat is the right thing. This isn't a 
Windows only problem.

Comment 52

[Brian Nesse (gone)]

A quick test of this in 4.x shows that we do indeed cache the file to disk (to 
cacheXXXXXXX.pdf). This file is subsequently deleted when the page is left. You 
can, however, duplicate the file while the page is open thus bypassing its 
deletion.

Comment 53

[lmcquarr]

I just modified the Acrobat plug-in to NOT request the PDF file
served via HTTPS as a file if the browser is mozilla ... and this
modification fixed this bug.  I will be checking this code into the first
service pack for Acrobat 5, ETA early fall.  

This means that there  **will be**  an upgrade path for customers who
experience this bug, if the mozilla team can not get another type of
fix in.  

There are, however, many millions of older versions of Acrobat out
there (like there are many millions of older versions of Netscape
browsers).  A mozilla fix, therefore, would also be desireable.

Comment 54

[Peter Lubczynski]

So "new" Acrobat installs should just work once the fix is in the service pack, 
right?

As for older Acrobats, I wonder if there is a way we can hack this? Should I 
spend any time on trying to do this or should we rel-note it?

Comment 55

[Mike Kaply [:mkaply]]

I beg you to try to come up with a fix for this.

some platforms (as in most non Windows) don't get Acrobat updates.

This might be fixed on Windows by Adobe, but it is still a Mozilla bug.

By the way, does anyone know if any other plugins have this problem? Have we 
tried Java applets or wav files on a secure server?

Comment 56

[Arun Ranganathan]

Hmm.. Liz McQuarrie repeatedly tells us that this isn't one of two important 
bugs (bug 53363 and bug 25699).  However, secure PDF is *crucial* to other 
folks.  Peter, see if you can throw together something for older Acrobats.  If 
not, more evangelism for me :-).  I'd like chrisn to make the final call. 

Comment 57

[Peter Lubczynski]

Looks like you won't have to evangelize too much because Liz will be making the 
changes. Maybe we should bump it up another version so we can come up with a 
hack for older Acrobats. 

We need caching code in plugins anyway for when the disk cache is turned off. I 
wonder if we could detect the version of the Adobe plugin or perhaps have a 
failsafe---cache the file if all else fails. Is this possible, Andrei, Dougt?

PDT: What do you think? Should we cache https only as a last resort only in 
plugins? I don't like the idea, but it doesn't seem that bad if it's a last 
resort and Nav 4.x and IE Mac do it. Perhaps a security rel-note?

Comment 58

[Phil Peterson]

I'm interested in how mkaply's examples work, or any other data to help us
decide if this is more of a compatibility issue or more of a security hole.
Would still like to hear from mstoltz and/or lord on the latter issue.

Comment 59

[lmcquarr]

Attachment: Version of Acrobat Plug-in That Works With SSL (4.X Bug Workaround is now bounded to not include mozilla)

Comment 60

[shrirang khanzode]

yep, works fine with the attached plugin on today's branch 0605 windows.

Comment 61

[Peter Lubczynski]

Because a solution is close at hand by an Acrobat refresh, I'm moving this off 
to mozilla0.9.3. If I run out of bugs, I'll come back to this.

Also, still need a security opinion....

Comment 62

[Mitchell Stoltz (not reading bugmail)]

We need someone on the PSM team to give a security opinion here. I know there
was a good reason for not caching SSL-delivered content, and the risk of bending
that rule seems to be the issue here. I don't know how big that risk is.

Comment 63

[Mike Kaply [:mkaply]]

OK, now I am just going to beg.

We need this fix for platforms BESIDES Windows.

Adobe's fix is ONLY for Windows.

If someone could just tell me how to hack around this in Mozilla, I would let 
this be pushed to 0.9.3, but right now I have banks that are rolling out stuff 
and this bug is huge.

The fix from Adobe only helps Adobe Windows customers.

Thanks for your support.

Comment 64

[Bob Lord]

It sounds like this is turning into a request for HTTPS object caching.  I
didn't see any PSM bug of that sort, so I created bug 84311.

Comment 65

[Doug Turner (:dougt)]

This is what you get when you propose the solution: more work ;-)

Comment 66

[Doug Turner (:dougt)]

Attachment: Patch to make plugins work over https.

Comment 67

[Doug Turner (:dougt)]

The last patch along with the patch in 86041 allow plugins to work over https.  
I have tested this *only* with the above link and have verified that (a) the PDF 
loads, (b) when exiting all temp files are removed, and (c) non-https PDFs still 
load correctly.


A couple of concerns with the last patch:

a) The patch only cleans up temp files on exit. Is this OKAY?  What about 
profile switching?  This task is still blocked by some of Peter's work...

b} Are we saving the location in the right places.  Currently is temp files are 
saved to <profile>/plugtmp.  What should the default location of these kinds of 
temp files be?  Please don't tell me /tmp or the equiv.  

c) Diskspace.  Maybe we should be checking for low disk space and cleanly 
failing.  Well, maybe necko should be doing this in ALOT of places... So, maybe 
it is not a serious concern now.

d) Embedders.  What if they want to change the destination of these files.  I 
think that we need to invent a new directory service location that references a 
"plugin temp directory".  

e) byte range requests over a security connection that also wants to do file 
cacheing... this 'boundary' case I don't want to even think about right now.  
Maybe someone can try it out and report back how bad this doesn't work.

Peter, Mike, Av, can you please review my changes.  

Comment 68

[av (gone)]

Just a couple of things. Why not to delete the file right after we close the 
stream? May it be needed for navigation? And second, would probably be cleaner 
to define "plugtmp" somewhere in the header file.

Comment 69

[Peter Lubczynski]

FYI: 4.x reference of what to do whith https and byte range streams:

http://lxr.netscape.com/nova/source/lib/plugin/npglue.c#2980

Comment 70

[Doug Turner (:dougt)]

Av, Why not to delete the file right after we close the stream... Well, if we
do, then the plugin never sees the file.  For whatever reasons, the stream is
closed as soon as onStopRequest if fired.  I origanally had the file being
deleted in the stream ~() but that didn't work.  Maybe peter can hook this
"early delete" up later?

new patch coming up which moves "plugtmp" static string to a header...

Comment 71

[Doug Turner (:dougt)]

Attachment: With Av's suggestion.

Comment 72

[Doug Turner (:dougt)]

can I get a r=/sr= on the last patch?  Peter, can you investigate what it will
take to have the temp file be deleted on page transition?  I think you have a
similar bug wrt leaks.

Comment 73

[Peter Lubczynski]

Doug,

In this patch:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=38711

I'm having the link list of "active" plugin instances,
nsPluginHostImpl::mActivePluginList, take hold a reference to the stream peer
for the "full-page" case. You can probably move that logic to the more general
case of nsPluginHostImpl::NewPluginURLStream.

Comment 74

[Doug Turner (:dougt)]

peter, I was hoping that you could solve this problem.

Comment 75

[Peter Lubczynski]

Okay, how about this: Can you put the delete file code in the destructor of the
stream (peer?) and I'll ensure the stream has a reference for the duration of
the plugin instance so the destructor won't get called until after the plugin
goes away?

Both of these patch will probably have to go in at the same time. 

Comment 76

[Doug Turner (:dougt)]

peter, I would rather not do this.  This would break this patch and I could not
mark this bug as FIX when I checked in.

Let do this.  Write up a new bug wrt the page transition delete, give me a r=,
and get av to look at this patch.  :-)

Comment 77

[Doug Turner (:dougt)]

I added code to the destructor nsPluginStreamInfo::~nsPluginStreamInfo() but
with peter's suggested patch, I am not hitting this delete (possible leak!)

Comment 78

[Peter Lubczynski]

Doug, my logic was completely wrong in that patch. Can you try my fixed up one:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=38936

I confirm that with this patch, nsPluginStreamInfo::~nsPluginStreamInfo() is
called when leaving the page.

Comment 79

[Doug Turner (:dougt)]

Okay.  that works for me.  I will add a delete in ~nsPluginStreamInfo().  I will
KEEP the delete in the nsPluginHostImpl::Destroy just to be safe.  Patch coming up.

Comment 80

[Doug Turner (:dougt)]

Attachment: deletes cached file in stream destructor.

Comment 81

[Doug Turner (:dougt)]

The last patch can only be used with peter's stream changes.

Comment 82

[Peter Lubczynski]

Do we need a special server to issue byte ranges?

junruh: can you put up one of the byte range testcase in bug 53363 on your
secure server for testing? My favorite is:
http://access.adobe.com/browser/netscape/readtesting/gotopage5.pdf

Comment 83

[John Unruh]

Here it is:
https://junruh.mcom.com/gotopage5.pdf

Comment 84

[Doug Turner (:dougt)]

The heavy lifting is done.  Reassigning to peter to seek permission to check in. 
 If there are any problems that come up, please let me know asap.

Comment 85

[av (gone)]

r=av. Although it is not easy to review two patches at once.

Comment 86

[Peter Lubczynski]

Attachment: complete patch (mine merged in, conflicts resolved)

Comment 87

[Marc Attinasi]

Well, if you all have decided that it is really OK to write https data to the
filesystem, then sr=attinasi on the patcy (id=38998) - sounds like a security
hole to me though (especially with access permissions set to 777).

Comment 88

[Asa Dotzler [:asa]]

a= [e-mail] for checkin to the trunk.
(on behalf of drivers)

Comment 89

[Peter Lubczynski]

I agree. Adding keyword relnote.

Arun, how do you ensure a relnote is added to the product?

Liz: How will these changes effect yours in Acrobat? We still want to stream
directly to Acrobat 5.x with your changes. Should we increment the version?

Patch checked in, marking FIXED.

Comment 90

[Doug Turner (:dougt)]

Marc, double check that.  The cached file should be opened as 00600.  

Comment 91

[Bob Clary [:bc] (inactive)]

verify fix works in trunk build 2001-06-18-23/Win2k

Comment 92

[John Unruh]

Verified on WinNT branch. On Mac, I get a crash.

Comment 93

[Doug Turner (:dougt)]

john, do you have a stack trace?  lets open a new bug for this problem.

Comment 94

[John Unruh]

Marking verified. I am opening a new bug for Mac and possibly Linux.

Comment 95

[John Unruh]

Reopening. This is reproducible again.

Comment 96

[serge (gone)]

WFM: w2k, Gecko/20020306 Netscape6/6.2.1+, https://pki.mcom.com/pingform.pdf
But there is a possibility to hang mozilla or 4.x  on *.pdf file if something 
bad happened in previous rpc session between acrobat plugin and Acrobat process, 
actually last one can just stall, in this case you won't be able to open any 
local pdf file. 
The solution: kill Acrobat.exe 

Comment 97

[Peter Lubczynski]

Yes, confirming that this is happening, but ONLY with Acrobat 5.05. The
orriginal Acrobat 5.0 works correctly. Strange....Liz, did anything change?

From the logs, everything looks correct that we are getting byte ranges and a
plugin instance is being created. However, the data never gets to the plugin!
We're not even updating progress in the status bar. A look in the debugger is
needed.

Although the symptoms may be the same, let's open a new bug as I don't think
this is going to be the same issue as this bug.

Comment 98

[shrirang khanzode]

v

Comment 99

[av (gone)]

I have just installed 5.1 and see blank page too.

Comment 100

[lmcquarr]

Hi Folks:

We have an the same pingform.pdf test case (or similar) on a secure
server here, but I am not seeing a blank page problem.  I am, seeing, however,
that the forms submission does not work with the 3/8 build. 

I will do a little more debugging on the forms submission problem.
In the meantime, it looks like I will need you folks to help
me get access to your test case for the blank page, since I can not
repo it here.

Comment 101

[Peter Lubczynski]

Confirming signing PDF's fails on NPN_Post on:
http://acroeng.adobe.com/BrowserTestSuite/forms/SubmitAsPDF.pdf

Created bug 130080 for this issue.

Comment 102

[serge (gone)]

Attachment: tester plugin release build

Comment 103

[serge (gone)]

woops, wrong bug report:(