90857 - Plugin causes cache file to not be created

Status: RESOLVED INVALID

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

Description

[Matthew Cline]

Build 2001071406, Linux 2.4.6-ac2 i686, RedHat 6.1, XFree86 4.1.0

When plugger tries to invoke ghostview on a PDF file, ghostview gives
the error that it can't open the file:

    ~/.mozilla/PROFILE_NAME/JUNK.slt/Cache/3F2D6480d01

This file doesn't exist.  This happens whether or not the memory cache
is on, and the "No-Cache" directive is *NOT* in the HTTP response
headers, so I don't know why it's not there.  In fact, as far as I can
tell, none of the files in the Cache directory are PDF files.

Comment 1

[Matthew Cline]

This seems like it might be simmilar to bug 89191, but I don't think
this is a dup of it, since that bug deals with machines that only
respond with HTTP/1.0, which is not the case for this bug.

I've found that this problem is somehow related to plugins, since if
the Plugger plugin doesn't try to handle PDF files, the appropriate
cache entry *is* created; I don't know why no cache entry is being
made for a file being handled with a plugin, since cache files are
apparently how Mozilla is trying to give files to plugins.

When testing this under a debug build, I get the error:

Error loading URL
http://oss.software.ibm.com/developer/opensource/linux/whitepapers/gkhi/ukuug01/GKHI-UKUUG.pdf
: 80004005 (NS_ERROR_FAILURE)

However, the Ethereal sniffer shows this HTTP get/response messages:

<<<<<<<<
GET /developer/opensource/linux/whitepapers/gkhi/ukuug01/GKHI-UKUUG.pdf HTTP/1.1
Host: oss.software.ibm.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2+) Gecko/20010523
Accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9,
image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css, */*;q=0.1
Accept-Language: en-us, en;q=0.80, en-gb;q=0.60, en-au;q=0.40, ja;q=0.20
Accept-Encoding: gzip,deflate,compress,identity
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Connection: keep-alive

HTTP/1.1 200 OK
Date: Mon, 16 Jul 2001 06:27:11 GMT
Server: Apache/1.3.12 (Unix) Red-Hat-Secure/3.2 ApacheJServ/1.1.2 PHP/3.0.18
Last-Modified: Mon, 18 Jun 2001 17:01:50 GMT
ETag: "7e026-1ebf9-3b2e33fe"
Accept-Ranges: bytes
Content-Length: 125945
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: application/pdf
>>>>>>>>>>

(The PDF file then follows.)  So Mozilla is barfing on reading the
file, for some reason, but it's getting the proper response, so it
shouldn't barf.

I used Preferences/Debug/Networking to turn off pipelining and HTTP
keepalive, and to change the HTTP protocol to 1.0, but none of this
helped any.  I also tried all of the different cache checking types
(Never, Once a Session, Every Time, and Automatic), but they all
resulted in the same behavior.

I'm sending this over to Plugins, since its PDF being handled by a
plugin that's somehow causing the problem with caching.

Comment 2

[gordon]

Moving to 0.9.8.

Comment 3

[Sergey Lunegov]

WFM on Linux RH 7.1 with CVS trunk build from 02012002.

Comment 4

[scottputterman]

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to [e-mail].  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.

Comment 5

[Matthias Versen [:Matti]]

Is this still a problem with recent builds ?

Comment 6

[Josh Aas]

Doubt it.