www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nigel Cole <N.C...@sc98c.demon.co.uk>
Subject os-solaris/7527: Large Acrobat files fail to download into plug-in
Date Thu, 05 Apr 2001 15:16:49 GMT

>Number:         7527
>Category:       os-solaris
>Synopsis:       Large Acrobat files fail to download into plug-in
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Thu Apr 05 08:20:00 PDT 2001
>Originator:     N.Cole@sc98c.demon.co.uk
>Release:        1.3.19
Solaris 2.6, Generic_105181-20, Ultra Enterprise (two machines running as a
high-availability server)
gcc 2.8.0
Almost every file system bar /tmp NFS mounted from an Auspex file server
Apache 1.3.19, 1.3.14, and 1.3.12 (to confirm it wasn't PR6711)
This is not the same bug as PR6711, but may be related to PR 5457.

When a large (about 1MB or more; it's not quite consistent, with an
occasional 2MB file working and a 0.7MB file failing) PDF file is accessed
via the Acrobat plug-in for Netscape Communicator, the following sequence
takes place:

1. An initial request for the entire file; response code 200, but only some
multiple of MMAP_SEGMENT_SIZE gets transferred (typically 32768).

2. A request with an If-Modified-Since header and a very long Range header;
response code 304, no data sent.

3. A request for part of the file from about 100k characters in (variable);
response code 206, rest of file sent.

No Acrobat file is visible in the plug-in. The plug-in has no problem
viewing the file if it is downloaded first and loaded from the local
filesystem, nor has it any problem viewing the file from a Netscape
Enterprise webserver on a different part of our network. Once the problem
had been discovered, I did most of my testing on a vanilla 1.3.12 install,
to make sure it wasn't caused by one of our non-standard modules or the
problem noted in PR6711.

The error log has a single entry, probably relating to the first request,
claiming "Broken pipe: client stopped connection before send mmap completed".
Sticking a lot of fprintfs in the code just confirmed that the write() system
call was failing with a EPIPE error.

Two different Solaris versions of Communicator were tried (4.51 and 4.74),
with plug-ins for Acrobat 3 and 4 respectively. Another user has reportedly
tried with NT versions of Communicator 4.74 and Internet Explorer 5.5, with
the same result.

My suspicion is some interaction between the plug-in, the socket code, and
the code for handling ranges (the file downloads without any problem if
Acrobat is launched as a helper application).

I note that PR5457, which describes a similar problem, is also for Apache
on an Sun Ultra running Solaris (though 2.5 rather than 2.6), so I also
suspect that it's peculiar to Solaris.
Our network is internal-only, unfortunately. It should be repeatable on a
Solaris system with a sufficiently large PDF file, together with Communicator
and the plug-in.
Sadly, no; I'm completely stumped at this point. There is a work-round (don't
use the Acrobat plug-in, use Acrobat as a helper app), but it's not ideal.
 [In order for any reply to be added to the PR database, you need]
 [to include <apbugs@Apache.Org> in the Cc line and make sure the]
 [subject line starts with the report component and number, with ]
 [or without any 'Re:' prefixes (such as "general/1098:" or      ]
 ["Re: general/1098:").  If the subject doesn't match this       ]
 [pattern, your message will be misfiled and ignored.  The       ]
 ["apbugs" address is not added to the Cc line of messages from  ]
 [the database automatically because of the potential for mail   ]
 [loops.  If you do not include this Cc, your reply may be ig-   ]
 [nored unless you are responding to an explicit request from a  ]
 [developer.  Reply only with text; DO NOT SEND ATTACHMENTS!     ]

View raw message