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.
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
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.
Retested with 2002040903. Problem still exists. Sorry, I can't test without using a proxy.
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).
tom: can you locate a netscape proxy server that we can use for testing? and can you try to reproduce this bug? thx!
ben is going to take a look at this
QA Contact: tever → benc
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.
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.
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 ?
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.
The testpage is gone. Does the bug still show up in 1.1 or later? If so, please provide new testcase. pi
Assignee: darin → dougt
Component: Networking: HTTP → Networking: File
Component: Networking: File → File Handling
No response, no testcase, marking WFM. pi
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.