Hi, We have a pdf file in our database, and there's a Problem with displaying it. Using the "native" Address http://multimedia.zawiw.uni-ulm.de/zope/solill/forum-guide.pdf both netscape 4.7 and mozilla 0.9.8 load the acrobat plugin, but don't display the file (the window just stays white or grey). I tested this with the linux versions, but one my users (the one who pointed me to this problem) is working with windows, and has the same problem. Fetching the via wget or via save-as right klick in a browser works fine, the retreived file can be viewed with acroread without problems. Also, accessing the document via https works fine, either through the management interface path https://multimedia.zawiw.uni-ulm.de/zmanager/zawiw/solill/forum-guide.pdf and via a https mapping of the native path https://multimedia.zawiw.uni-ulm.de/zope/solill/forum-guide.pdf - in both cases, netscape just displays the file via pdf plugin. Does anyone have any idea what's happening here? Feel free to try to download the file for yourself for diagnostic purposes. I'm running zope 2.4.2-0.2 behind apache 1.3.23-1 on linux/2.4.18, all debian testing packets. markus -- Markus Schaber - http://www.schabi.de/ Check in to another world - test a _real_ OS.
Markus Schaber wrote:
Hi,
We have a pdf file in our database, and there's a Problem with displaying it.
Using the "native" Address http://multimedia.zawiw.uni-ulm.de/zope/solill/forum-guide.pdf both netscape 4.7 and mozilla 0.9.8 load the acrobat plugin, but don't display the file (the window just stays white or grey). I tested this with the linux versions, but one my users (the one who pointed me to this problem) is working with windows, and has the same problem.
Fetching the via wget or via save-as right klick in a browser works fine, the retreived file can be viewed with acroread without problems.
Also, accessing the document via https works fine, either through the management interface path https://multimedia.zawiw.uni-ulm.de/zmanager/zawiw/solill/forum-guide.pdf and via a https mapping of the native path https://multimedia.zawiw.uni-ulm.de/zope/solill/forum-guide.pdf - in both cases, netscape just displays the file via pdf plugin.
Does anyone have any idea what's happening here?
Feel free to try to download the file for yourself for diagnostic purposes.
I'm running zope 2.4.2-0.2 behind apache 1.3.23-1 on linux/2.4.18, all debian testing packets.
markus
Hi markus, just FYI, it didn't work for me with the first https url also. There are some problems when viewing pdfs in-browser comes into play. IIRC byterange serving may be involved, see the thread at http://aspn.activestate.com/ASPN/Mail/Message/zope-List/683104 for instance (the acrobat plugin). Note that this also concerns some braindead commercial SOHO proxies, not only zope, but this is not the case here (we have no such beast, unfortunately some of our clients ;-(). Are you using PCGI of FCGI? cheers, oliver
Hi, Oliver Bleutgen wrote:
Hi markus, just FYI, it didn't work for me with the first https url also. There are some problems when viewing pdfs in-browser comes into play. IIRC byterange serving may be involved, see the thread at http://aspn.activestate.com/ASPN/Mail/Message/zope-List/683104 for instance (the acrobat plugin).
Okay, I'll take a look there.
Are you using PCGI of FCGI?
Neither-Nor, I use mod_rewrite with P rules and a virtual host monster. Markus -- "Ihre Meinung ist mir zwar widerlich, aber ich werde mich dafuer totschlagen lassen, dass sie sie sagen duerfen." - Voltaire
-> > We have a pdf file in our database, and there's a Problem with -> > displaying it. Please descibe the web hosting setup this is being served from. I.e., what O.S. is the origin server, are there any proxies involved (and what are their O.S.'s), is there any kind of caching being done, etc. Also, is Apache anywhere in the chain (perhaps as a caching proxy)? Are there any load-balancing routers in the way? We saw the same thing in a system that involved Windows NT talking to a Solaris proxy. Sun has a stupid yet (they believe) technically correct TCP/IP stack, and Windows NT has a just plain broken TCP/IP stack. Together they can cause this PDF problem. It has to do with payload-less FIN packets or out-of-order FIN packets. --Derek
Hi, Derek Simkowiak wrote:
-> > We have a pdf file in our database, and there's a Problem with -> > displaying it.
Please descibe the web hosting setup this is being served from. I.e., what O.S. is the origin server, are there any proxies involved (and what are their O.S.'s), is there any kind of caching being done, etc. Also, is Apache anywhere in the chain (perhaps as a caching proxy)? Are there any load-balancing routers in the way?
It was using IE on Win, Netscape 4.7 on Linux and Mozilla 0.9.8 on Linux. This seems to imply that it's a problem with the acroread plugin, and not with the OS or the Browser. The windows machine was on the same subnet (I think a switch was inbetween, but might be a bridge), the linux client had some routers inbetween, but no load balancing. The server is an debian woody on linux 2.4.17, Apache 1.3.23-1 using mod-rewrite using proxy rules [P] to hide zope 2.4.2-0.2, all the precompiled debian packages. We currently "solved" the problem by putting the file into a directory where it is served directly by apache, and this seems to work. Markus -- "Ihre Meinung ist mir zwar widerlich, aber ich werde mich dafuer totschlagen lassen, dass sie sie sagen duerfen." - Voltaire
-> Linux. This seems to imply that it's a problem with the acroread plugin, -> and not with the OS or the Browser. Not necessarily. The Acroread plugin fires up as soon as it sees the Content-Type: header. The browser is still the one managing the TCP/IP and HTTP connections. But Acroread won't display anything on the screen until it has the entire document--this is different from HTML, where browsers try to render as much as they can as soon as they can. It might be a problem with HTTP 1.1 chunks... If you have the time, do this: Do an ethereal sniff of a single (failed) PDF request, save that as a parsed, human-readable text file (I don't remember the ethereal options), and then post it somewhere via HTTP and send the URL to the mailing list. I will download it and take a look at it. --Derek
participants (3)
-
Derek Simkowiak -
Markus Schaber -
Oliver Bleutgen