136560 - Cannot load a pdf file linked from this page

Status: VERIFIED WORKSFORME

(Core Graveyard :: File Handling, defect)

Description

[adrian godwin]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.9) Gecko/20020311
BuildID:    2002031104

There's a pdf file linked from this page that Mozilla doesn't want to save (it
times out attempting to load the link target). IE6 can do it OK.


Reproducible: Always
Steps to Reproduce:
1.right clock on link to PDF
2.choose 'save link as..'
3.

Actual Results:  there is a delayof a few sceonds  and eventually a dialog box
indicating that the file can't be loaded and 'might have moved or had its name
changed'. 

Expected Results:  Saved the file. Works OK in IE6.


The build I'm using seems to have become a lot less usable recently - in many
cases I follow a link or type a URL and nothing whatever happens. Reload usually
reloads the already-displayed page and re-doiing the operation quite often
works. Perhaps the reported problem is a special case of the same fault.

Maybe it's my imagination, but I think this behaviour may have started after I
performed a recent MS update (the 'big security patch'). However, I had not
previously updated the machine (NT4) so this could have made quite a lot of
changes. I removed and reinstalled Moz 0.99 in an attempt to fix this (maybe the
MS update broke something ?) but without improvement.

Comment 1

[Boris 'pi' Piwinger]

Works in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020405 and
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9+) Gecko/20020409.

pi

Comment 2

[adrian godwin]

Attempted to retest with most recent nightly build (as of 10.4.2002) but that
build  doesn't start on this system. Reverting to 2002031104 still shows
problem. Note that in reverting some proxy info was lost (http proxy socket now
blank, direct connection reselected). My connection is via a netscape proxy :
maybe this is relevant to reprocucing the bug.
 

Comment 3

[adrian godwin]

Retested with 2002040903.
Problem still exists.
Sorry, I can't test without using a proxy.

Comment 4

[Sitsofe Wheeler]

I can't reproduce this with 20020409 Linux i686 and I'm connecting to a proxy
too (I doubt it is a Netscape proxy though).

Comment 5

[Darin Fisher]

tom: can you locate a netscape proxy server that we can use for testing?  and
can you try to reproduce this bug?  thx!

Comment 6

[Tom Everingham]

ben is going to take a look at this

Comment 7

[[not reading bugmail]]

I cant get pdfs to load either in rc2, 5-18-08 nightly on winxp or any other
recent build.. this used to work.  I think it should be nominated for mozilla 1.0.

Comment 8

[adrian godwin]

It's not all pdfs - the particular one (or the particular site) fails
consistently. This occurs also on RC2, but I can still load others.

If our proxy is to blame (it's probably rather overloaded and is often quite
slow), it may also be noteworthy that I very often get a 'page has no content'
error, but  will succeed on retrying. Retrying the pdf load doesn't seem to help.

Comment 9

[adrian godwin]

This problem is largely fixed by changing the HTTP Networking preference to use
HTTP 1.0. Use of persistent connections does not affect it, and pipelining was
turned off anyway so the automatic disabling caused by changing protocol is
irrelevant (tested with release 1.0 on NT4, still behind the NS proxy).

I say 'largely' fixed because there is still a peculiarity : left-clicking on
PDF file link results in the message 'File does begin with %PDF', but if the
file is saved (save link target) it can be seen to start '%PDF-1.1'. ACrobat 5.0
will also load this saved file happily. However, this is a major improvement
over the original behaviour where the file could not be retrieved at all.

I'm ignorant about the differences between HTTP 1.0 and 1.1, and their possible
interactions with proxies. If there is often a problem, would it be helpful to
note this in the proxy setting preference ?

Comment 10

[adrian godwin]

Sorry, I didn't test all combinations of persistent connections and protocol choice.

If HTTP 1.0 is selected, the persistent conneciton choice has no effect -
transfers  are OK either way.

If HTTP 1.1 is selected and persistent connections are disabled, transfers are OK.

If HTTP 1.1 is selected and persistent connections enabled, the transfer fails.


Making this change has improved the performance of many, many other links which
were previously slow or took several attempts before they'd work, but the link
described remains a good pass / fail test.

Comment 11

[Boris 'pi' Piwinger]

The testpage is gone. Does the bug still show up in 1.1 or later? If so, please
provide new testcase.

pi

Comment 12

[benc]

->file handling

Comment 13

[benc]

again...

Comment 14

[Boris 'pi' Piwinger]

No response, no testcase, marking WFM.

pi

Comment 15

[sairuh (rarely reading bugmail)]

v