Last Comment Bug 420310 - unable to display PDF delivered via SSL since Firefox 2.0.0.10
: unable to display PDF delivered via SSL since Firefox 2.0.0.10
Status: VERIFIED FIXED
: regression, testcase, verified1.8.1.17, verified1.9.0.2
Product: Core
Classification: Components
Component: Networking: HTTP (show other bugs)
: 1.8 Branch
: x86 Windows XP
: -- normal (vote)
: ---
Assigned To: neil@parkwaycc.co.uk
:
:
Mentors:
https://ananke.softeu.cz/pdf/public/
Depends on: 345181
Blocks: 402460 444345
  Show dependency treegraph
 
Reported: 2008-02-29 08:30 PST by Adam Hauner
Modified: 2008-09-09 12:49 PDT (History)
13 users (show)
dveditz: blocking1.8.1.17+
dveditz: wanted1.8.1.x+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
livehttpheaders output of Gecko/20071113 and Gecko/20071114 (2.08 KB, text/plain)
2008-03-03 01:21 PST, Adam Hauner
no flags Details
HTTP log 1.8-20071113 (64.79 KB, text/plain)
2008-03-04 06:05 PST, Adam Hauner
no flags Details
HTTP log 1.8-20071114 (38.34 KB, text/plain)
2008-03-04 06:08 PST, Adam Hauner
no flags Details
Proposed patch (929 bytes, patch)
2008-08-21 02:52 PDT, neil@parkwaycc.co.uk
jst: review+
jst: superreview+
dveditz: approval1.8.1.17+
dveditz: approval1.9.0.2+
Details | Diff | Splinter Review

Description Adam Hauner 2008-02-29 08:30:45 PST
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 [:bz] (still a bit busy) 2008-02-29 08:50:32 PST
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 [:bz] (still a bit busy) 2008-02-29 08:51:23 PST
jst, see comment 1?
Comment 3 Adam Hauner 2008-02-29 09:12:13 PST
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] 2008-02-29 09:26:37 PST
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 [:bz] (still a bit busy) 2008-02-29 09:37:22 PST
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 2008-03-01 05:14:32 PST
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 [:bz] (still a bit busy) 2008-03-01 10:00:38 PST
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 2008-03-03 01:21:17 PST
Created attachment 307001 [details]
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 [:bz] (still a bit busy) 2008-03-03 11:52:43 PST
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] 2008-03-03 12:00:01 PST
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 2008-03-04 06:05:44 PST
Created attachment 307224 [details]
HTTP log 1.8-20071113
Comment 12 Adam Hauner 2008-03-04 06:08:04 PST
Created attachment 307226 [details]
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 [:bz] (still a bit busy) 2008-03-04 08:50:15 PST
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 [:bz] (still a bit busy) 2008-03-04 10:35:19 PST
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 [:bz] (still a bit busy) 2008-03-04 10:46:05 PST
I meant "from bug 402460".
Comment 16 Adam Hauner 2008-03-04 11:56:44 PST
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 [:bz] (still a bit busy) 2008-03-04 12:01:59 PST
Aha!  So yeah, something is going wrong with CreateUnique, somehow.
Comment 18 neil@parkwaycc.co.uk 2008-03-04 14:46:12 PST
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 [:bz] (still a bit busy) 2008-03-04 15:03:04 PST
Hrm... Shouldn't we be creating the file inside plugtmp?
Comment 20 neil@parkwaycc.co.uk 2008-03-06 05:08:47 PST
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 2008-03-06 08:12:12 PST
(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] 2008-06-02 11:42:28 PDT
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 neil@parkwaycc.co.uk 2008-06-02 11:54:56 PDT
Sorry, I can't work out how to work around the bug without a test case.
Comment 24 Daniel Veditz [:dveditz] 2008-06-05 14:57:34 PDT
Not going to be able to land bug 345181 in this release, -> 1.8.1.16
Comment 25 Adam Hauner 2008-07-09 07:54:08 PDT
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) 2008-08-11 11:39:11 PDT
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 [:bz] (still a bit busy) 2008-08-19 20:53:08 PDT
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 [:bz] (still a bit busy) 2008-08-19 21:16:33 PDT
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 [:bz] (still a bit busy) 2008-08-19 21:30:25 PDT
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) 2008-08-20 15:28:55 PDT
Neil, does that testcase help?
Comment 31 Adam Hauner 2008-08-21 01:37:32 PDT
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 neil@parkwaycc.co.uk 2008-08-21 02:14:19 PDT
(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 neil@parkwaycc.co.uk 2008-08-21 02:52:09 PDT
Created attachment 334857 [details] [diff] [review]
Proposed patch

This is a CVS patch because I was testing it on branch.
Comment 34 Boris Zbarsky [:bz] (still a bit busy) 2008-08-21 07:08:35 PDT
"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, jst@mozilla.com) 2008-08-25 23:01:55 PDT
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 neil@parkwaycc.co.uk 2008-08-26 05:03:54 PDT
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 neil@parkwaycc.co.uk 2008-08-26 05:05:33 PDT
Comment on attachment 334857 [details] [diff] [review]
Proposed patch

Simple regression fix.
Comment 38 Boris Zbarsky [:bz] (still a bit busy) 2008-08-26 05:41:30 PDT
> 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 neil@parkwaycc.co.uk 2008-08-26 07:45:15 PDT
OK, I'll mark this fixed, although trunk is actually tracked by bug 444345.
Comment 40 Daniel Veditz [:dveditz] 2008-08-26 14:29:25 PDT
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 neil@parkwaycc.co.uk 2008-08-26 15:47:55 PDT
Fix checked in.
Comment 42 Stephen Donner [:stephend] 2008-08-31 15:59:19 PDT
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] 2008-09-09 12:30:31 PDT
Stephen, can you verify this with the final 3.0.2 candidate build too?
Comment 44 Stephen Donner [:stephend] 2008-09-09 12:49:36 PDT
(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.

Note You need to log in before you can comment on or make changes to this bug.