420310 - unable to display PDF delivered via SSL since Firefox 2.0.0.10

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect)

Description

[Adam Hauner]

Our intranet web application is providing PDF files for its users. PDF files are returned as inline content (for displaying inside browser window).

Since Firefox 2.0.0.10 release users has not been able to display PDF files from application inside browser window. Tab with PDF has "(application/pdf object)" title, but it doesn't refresh and display previous tab content or content of other tab window. PDF files found on Internet are normally displayed without problems.

Maybe is important, that PDF is comming form SSL site with Cache-Control set to public.

I'm CCing Boris (for bug 402649), Christian (for bug 345181) and Daniel (it's stable branch regression). I do apologize, if such CC'ing is inappropriate.

Regression window on 1.8 branch:
...
2007111303 - ok
2007111404 - broken - fixes for bug 402649 and bug 402460 checked in on branch
2007111503 - broken
2007111504 - broken
...
20080228   - broken - 2.0.0.13pre

Checkings in that time window (check parameters):
http://tinyurl.com/24e3a6

Note: SeaMonkey 1.1.8 (1.8.1.12/20080201) has no problem with displaying PDF file.

On trunk this bug was already fixed:
...
2007111104 - ok     
2007111204 - broken - fixes for bug 402649 and bug 402460 checked in on trunk
...
2007113005 - broken
2007120105 - ok     - fixes for bug 262116 and bug 345181 checked in
...

Daniel's comment - bug 345181 comment #14

HTTP header of response:

  HTTP/1.x 200 OK
  Date: Fri, 29 Feb 2008 11:07:00 GMT
  Server: Apache/2.0.55 (Ubuntu) mod_jk2/2.0.4 PHP/5.1.2 mod_ssl/2.0.55 OpenSSL/0.9.8a
  Expires: Sat, 28 Feb 2009 11:07:00 GMT
  Cache-Control: public, max-age=31536000
  content-disposition: inline; filename="FEP08-2162 2008-02-06_15-30-47.pdf"
  Content-Type: application/pdf
  Content-Length: 6787
  Keep-Alive: timeout=15, max=98
  Connection: Keep-Alive

All tested with Adobe Acrobat 8.1.0. I could provide PDF file or access to application for developer.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Plug-ins depend on being able to cache as file, iirc.  That might be why the cache-control thing helped....

That said, I see no HTTP or plug-in changes in the original regression range, and I wouldn't have expected the window.location thing to affect this...  Is your application doing something interesting from unload handlers?  Do you hit the docshell code added in bug 402649?

Sadly, I doubt I'll have time to debug this in time for 1.8.0.13.  jst, do you think you could possibly take a look?

Comment 2

[Boris Zbarsky [:bzbarsky]]

jst, see comment 1?

Comment 3

[Adam Hauner]

Setting "browser.cache.disk_cache_ssl" to "true" (as oposite for default "false") is workaround for this bug, so this is probably problem with caching files delivered via SSL.

Moving bug to Networking.

(In reply to comment #1)
> That said, I see no HTTP or plug-in changes in the original regression range,

I can't see any checking in regression window on branch, which could be related to caching SSL files. =( Maybe I set wrongly query on Bonsai...

> and I wouldn't have expected the window.location thing to affect this...  Is
> your application doing something interesting from unload handlers?  Do you hit
> the docshell code added in bug 402649?

PDF is delivered on direct URL: you send GET request and get PDF file as response, so probably answer is no. For second answer I don't know answer.

Comment 4

[Pavel Cvrcek [:JasnaPaka]]

Just for info. With latest Firefox Trunk our application works fine but there was a problem too. I will try to find regression window and bug which fixed this problem on trunk.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Adam, can you do HTTP logs in the two branch nightlies (the one before the regression and the one after) and attach them here?  Ideally, just start the browser with the URI of the PDF, wait for it to load, then quit, if that shows the bug.  Make sure that during this test run one nightly shows the bug, and the other doesn't...

Comment 6

[Seshendra]

Found a similar issue with 2.0.0.12 today.

We earlier used to have the URL executed on our own server and worked absolutely fine even in 2.0.0.12, but in the current scenario we are having a single sign on (SSO) webserver intercepting our request. This is breaking our functionality in 2.0.0.12 but surprisingly working fine in mozilla version 2.0.0.6 or below.

Http Header values 

SUCCESS:

POST /******/authreg/pdf HTTP/1.1
Host: **********.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://*******/portal/site/******/authreg/StatementsAndDocuments/
******

Cookie: lastLogin=*****;  HTTP/1.x 200 OK
Date: Sat, 01 Mar 2008 11:38:52 GMT
Server: IBM_HTTP_Server
***********
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/pdf
Content-Language: en

--------------------------------------------------------------------------------

FAILURE

Cache-Control: no-cache
Keep-Alive: timeout=15, max=94
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
Content-Language: en

This also works on all versions of IE and other browsers.

We just want to rule out any probability of our design changes in our application breaking the PDF rendering on Mozilla 2.0.0.12.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Comment 6 doesn't sound related to this bug, unless it used to work with earlier branch releases.  I'd start by fixing your server to not claim that the PDF is text/html, for what it's worth.

Comment 8

[Adam Hauner]

Attachment: livehttpheaders output of Gecko/20071113 and Gecko/20071114

(In reply to comment #5)
> Adam, can you do HTTP logs in the two branch nightlies (the one before the

Hope, that LiveHTTPHeaders output is enough.

Comment 9

[Boris Zbarsky [:bzbarsky]]

It's not.  I need to see details about whether we're hitting the cache, etc.  There are instructions explaining how to get an HTTP log at http://www.mozilla.org/projects/netlib/http/http-debugging.html

Comment 10

[Daniel Veditz [:dveditz]]

Given the code freeze in a couple days I doubt we'll get a fix in time for 1.8.1.13 so "blocking" seems more faith-based than realistic. But if we _do_ get a patch please request approval.

I'm not sure the mere headers are enough for debugging (same requests, same responses), actual logging will show more information like error states and such: http://www.mozilla.org/projects/netlib/http/http-debugging.html

Comment 11

[Adam Hauner]

Attachment: HTTP log 1.8-20071113

Comment 12

[Adam Hauner]

Attachment: HTTP log 1.8-20071114

Both logs were truncated little before request on PDF, so loading browser start-page and login to application is not included. Cache was cleared before logging.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Hmm.  Nothing jumps out at me there.  In comment 0, you said you might be able to give access for someone to debug.  Can we do that?

Comment 14

[Boris Zbarsky [:bzbarsky]]

OK.  So I did a little more digging.  Calling SetCacheAsFile() of course fails.  So we end up under nsPluginStreamListenerPeer::SetupPluginCacheFile.  This gets the plugin temp dir, and then uses CreateUnique in that dir.  So I'll bet money this is a regression from bug 

Comment 15

[Boris Zbarsky [:bzbarsky]]

I meant "from bug 402460".

Comment 16

[Adam Hauner]

Loading PDF file from perspective of Windows TEMP directory:
1.8-20071113
c:\temp\plugtmp\    - created, empty
c:\temp\plugtmp-1   - created, size of PDF file

1.8-20071114
c:\temp\plugtmp\    - created, empty
c:\temp\plugtmp-1   - MISSING

Comment 17

[Boris Zbarsky [:bzbarsky]]

Aha!  So yeah, something is going wrong with CreateUnique, somehow.

Comment 18

[[e-mail]]

Stupid Windows.

If you try to create an existing directory you get ERROR_ALREADY_EXISTS, but if you try to create a file and a directory exists you get ERROR_ACCESS_DENIED, which is the same error that you get if no file exists but cannot be created.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Hrm... Shouldn't we be creating the file inside plugtmp?

Comment 20

[[e-mail]]

OK, so it looks like different callers abuse CreateUnique in different ways; some callers, such as SafeOutputStream, want to create a backup file, which somewhat assumes that there is an original file, and don't mind failing if they can't back up a directory. Here however I guess we really want a temporary file, but we don't have an API for that, which is why we're faking it.

Comment 21

[Seshendra]

(In reply to comment #7)
> Comment 6 doesn't sound related to this bug, unless it used to work with
> earlier branch releases.  I'd start by fixing your server to not claim that the
> PDF is text/html, for what it's worth.
> 

Boris, this was indeed working with earlier versions i.e 2.0.0.6 which I could test with. I Couldn't figure out why this is only failing in the current versions. I even tried with the latest nightly build (minefield), but was not successful. I cannot fix the text/html stuff because the intercepting server is owned by a third party.

Comment 22

[Daniel Veditz [:dveditz]]

Neil: are you still working on this one? the 1.8.1.15 code-freeze is coming soon so we need to know if that's a realistic expectation.

Comment 23

[[e-mail]]

Sorry, I can't work out how to work around the bug without a test case.

Comment 24

[Daniel Veditz [:dveditz]]

Not going to be able to land bug 345181 in this release, -> 1.8.1.16

Comment 25

[Adam Hauner]

I filled bug 444345 for similar problem with PDF delivered with cache-control:private as regression since Firefox 3.0b2.

Changing bug summary to better reflect what is know about this bug.

Comment 26

[Samuel Sidler (old account; do not CC)]

So we need a testcase for this. Is that simply a PDF on an SSL server with cache-control:public set?

Comment 27

[Boris Zbarsky [:bzbarsky]]

Uh... Wouldn't a testcase just be the set of CreateUnique calls that happen here?  That is, just an xpcshell test?

If Neil means he needs to see what exactly the plug-in code is doing, all that's needed is a PDF file on an SSL server.  That's enough for branch.  For trunk it also must not be sending "Cache-control: public".

Comment 28

[Boris Zbarsky [:bzbarsky]]

OK, scratch that.

To get this bug to trigger we need to have a temp dir and be creating a temp _file_, right?  I think the only way we can hit that is to have a URI with an empty leafName that comes back as a PDF (the URI in the HTTP log is just such a URI).

So in addition to what I said in comment 27, the URI the PDF is coming from needs to be of the form https://some.host.here/some/path/ with nothing after the last slash.

This shouldn't be hard to set up for someone with clue and access to a .htaccess file on a reasonable Apache install.  Just create a directory, put a PDF named test.pdf in it (https://bugzilla.mozilla.org/attachment.cgi?id=334617 if you can't find one), put "DirectoryIndex test.pdf" in the .htaccess, and you should be set.

Comment 29

[Boris Zbarsky [:bzbarsky]]

There's a testcase for this bug now at https://landfill.bugzilla.org/ryl/pdf-test/ or so I hope.  I don't have a Windows machine to reproduce with offhand.

Comment 30

[Samuel Sidler (old account; do not CC)]

Neil, does that testcase help?

Comment 31

[Adam Hauner]

Changing testcase to https://ananke.softeu.cz/pdf/public/ - it contains in response cache-control property with right values:

HTTP/1.x 200 OK
Date: Thu, 21 Aug 2008 08:33:31 GMT
Server: Apache
X-Powered-By: PHP/4.3.10-19
Expires: Sat, 28 Feb 2009 11:07:00 GMT
Cache-Control: public, max-age=31536000
content-disposition: inline; filename='public.pdf'
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 11929
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: application/pdf

https://landfill.bugzilla.org/ryl/pdf-test/ is not correct testcase, I can't reproduce bug with Fx 2.0.0.16, because response doesn't contain cache-control property:

HTTP/1.x 200 OK
Date: Thu, 21 Aug 2008 08:31:36 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Wed, 20 Aug 2008 04:20:23 GMT
Etag: "99542a-73b4-85e8afc0"
Accept-Ranges: bytes
Content-Length: 29620
Connection: close
Content-Type: application/pdf
X-Pad: avoid browser bug

Comment 32

[[e-mail]]

(In reply to comment #19)
> Hrm... Shouldn't we be creating the file inside plugtmp?
Without a file name, we try to create the file next to plugtmp.
Is there a particular need to use the URL's file name?

Comment 33

[[e-mail]]

Attachment: Proposed patch

This is a CVS patch because I was testing it on branch.

Comment 34

[Boris Zbarsky [:bzbarsky]]

"Cache-control: public" shouldn't matter on branch, and makes the bug disappear on trunk, no?  So why is that the correct thing for the testcase?

Neil, I doubt it's that important to have the exact filename from the URI.

But it still seems to me that there's a fundamental bug in CreateUnique here, where it will fail in some cases where it should succeed.  Working around it in the plug-in code is fine, but we should fix XPCOM too, no?

Comment 35

[Johnny Stenback (:jst)]

Comment on attachment 334857 [details] [diff] [review]
Proposed patch

Looks like a good workaround, bug please file the XPCOM bug on this problem too.

Comment 36

[[e-mail]]

Pushed changeset 3848ffd8a143 to mozilla-central.
Leaving this bug open until branch checkins have landed.

(In reply to comment #35)
> please file the XPCOM bug on this problem too.
Filed bug 452217 against XPCOM.

Comment 37

[[e-mail]]

Comment on attachment 334857 [details] [diff] [review]
Proposed patch

Simple regression fix.

Comment 38

[Boris Zbarsky [:bzbarsky]]

> Leaving this bug open until branch checkins have landed.

Note that the bug probably needs to be resolved for the branch driver queries to properly pick up its state (fixed on trunk, etc).

Comment 39

[[e-mail]]

OK, I'll mark this fixed, although trunk is actually tracked by bug 444345.

Comment 40

[Daniel Veditz [:dveditz]]

Comment on attachment 334857 [details] [diff] [review]
Proposed patch

Approved for 1.9.0.2 and 1.8.1.17, a=dveditz for release-drivers.

Comment 41

[[e-mail]]

Fix checked in.

Comment 42

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED.

I can reproduce the bug with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16, but not with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/20080829 Firefox/2.0.0.17, using https://ananke.softeu.cz/pdf/public/ as the testcase URL.

Replacing fixed1.8.1.17 with verified1.8.1.17.

Comment 43

[Al Billings [:abillings - ex-MoCo]]

Stephen, can you verify this with the final 3.0.2 candidate build too?

Comment 44

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #43)
> Stephen, can you verify this with the final 3.0.2 candidate build too?

Verified FIXED using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.2) Gecko/2008090514 Firefox/3.0.2.

Replacing fixed1.9.0.2 keyword with verified1.9.0.2.

Also, as Neil says in comment 39, trunk is covered by bug 444345, so also marking as Verified.