serving files through SSL
I am trying to deliver some PDFs to the browser using my tomcat
application. It works, but not always under SSL and IE.
One file is a static PDF and it lives inside my war file. That works
just fine. The file is accessed using a url like /myapp/web/myfile.pdf
and that always delivers the file.
Other files are generated by the app and live in a configured directory.
They are delivered through a servlet that looks like this:
String mimeType = sc.getMimeType(filename);
FileHelper helper = new FileHelper();
InputStream in = helper.fetch(filename, m_dir);
response.setContentType(mimeType);
response.setContentLength(10115);
response.addHeader("ETag","W/\"963288-1194247031062");
OutputStream out = response.getOutputStream();
byte[] buf = new byte[1024];
int count = 0;
while ((count = in.read(buf)) >= 0)
{
out.write(buf, 0, count);
}
in.close();
out.close();
So apart from some minor fiddling with the contentType etc I don't do
very much. This works fine outside of SSL and it also works fine with
SSL and Firefox, but not SSL+IE.
Thinking it was a problem with headers I did some research and found a
lot of stuff about setting no cache etc. Tried it and it nothing made
any difference (except that I managed to break it). I have taken all
those out because the static file, the one I mentioned at first, is
delivering okay to IE over SSL so I don't believe there is a problem at
the IE end, or not one that cannot be overcome by getting my response
right at the server end.
I used TCPMonitor to sniff the headers using non-SSL and found that the
static file has this response:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
ETag: W/"963288-1194247031062"
Last-Modified: Mon, 05 Nov 2007 07:17:11 GMT
Content-Type: application/pdf
Content-Length: 963288
Date: Wed, 07 Nov 2007 04:54:39 GMT
... pdf file follows
So there doesn't seem to be too much going on there.
When I respond to the request for the dynamic file it looks like this:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 12:00:00 NZST
ETag: W/"963288-1194247031062
Content-Type: application/pdf
Content-Length: 10115
Date: Wed, 07 Nov 2007 05:32:02 GMT
...pdf file follows.
I am getting some cache headers added for free otherwise there is no
difference in the request.
Of course those headers may be making all the difference because IE's
message is 'cannot write the file to cache' which is a bit odd because
we've explicitly told it not to here.
Searching the web on this has a number of answers that suggest adding
those no-cache headers anyway.
So, does anyone know what I need to do to make the two responses enough
the same to stop IE complaining?
I am aware that I have faked the ETag and the length of the file and
that I need to do something smarter there, but I'll do that when it
starts working.
Version info: Tomcat 5.5, Java 1.5, WinXP SP2
Thanks for your help.
Roger
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: serving files through SSL
Roger Parkinson wrote:
I am trying to deliver some PDFs to the browser using my tomcat
application. It works, but not always under SSL and IE.
One file is a static PDF and it lives inside my war file. That works
just fine. The file is accessed using a url like /myapp/web/myfile.pdf
and that always delivers the file.
Other files are generated by the app and live in a configured
directory. They are delivered through a servlet that looks like this:
String mimeType = sc.getMimeType(filename);
FileHelper helper = new FileHelper();
InputStream in = helper.fetch(filename, m_dir);
response.setContentType(mimeType);
response.setContentLength(10115);
response.addHeader("ETag","W/\"963288-1194247031062");
OutputStream out = response.getOutputStream();
byte[] buf = new byte[1024];
int count = 0;
while ((count = in.read(buf)) >= 0)
{
out.write(buf, 0, count);
}
in.close();
out.close();
So apart from some minor fiddling with the contentType etc I don't do
very much. This works fine outside of SSL and it also works fine with
SSL and Firefox, but not SSL+IE.
Thinking it was a problem with headers I did some research and found a
lot of stuff about setting no cache etc. Tried it and it nothing made
any difference (except that I managed to break it). I have taken all
those out because the static file, the one I mentioned at first, is
delivering okay to IE over SSL so I don't believe there is a problem
at the IE end, or not one that cannot be overcome by getting my
response right at the server end.
I used TCPMonitor to sniff the headers using non-SSL and found that
the static file has this response:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
ETag: W/"963288-1194247031062"
Last-Modified: Mon, 05 Nov 2007 07:17:11 GMT
Content-Type: application/pdf
Content-Length: 963288
Date: Wed, 07 Nov 2007 04:54:39 GMT
... pdf file follows
So there doesn't seem to be too much going on there.
When I respond to the request for the dynamic file it looks like this:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 12:00:00 NZST
ETag: W/"963288-1194247031062
Content-Type: application/pdf
Content-Length: 10115
Date: Wed, 07 Nov 2007 05:32:02 GMT
...pdf file follows.
I am getting some cache headers added for free otherwise there is no
difference in the request.
Of course those headers may be making all the difference because IE's
message is 'cannot write the file to cache' which is a bit odd because
we've explicitly told it not to here.
Searching the web on this has a number of answers that suggest adding
those no-cache headers anyway.
So, does anyone know what I need to do to make the two responses
enough the same to stop IE complaining?
I am aware that I have faked the ETag and the length of the file and
that I need to do something smarter there, but I'll do that when it
starts working.
Version info: Tomcat 5.5, Java 1.5, WinXP SP2
Are you calling the dynamic PDF URL directly? For instance typing in the
URL directly in the browser?
The reason I am asking, is that for mixed responses from SSL requests,
IE puts up a warning, whereas FF does not.
--
Regards
Gabe Wong
NGASI AppServer Manager
Application server installation and configuration AUTOMATION
http://www.ngasi.com
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: serving files through SSL
In both cases the URL is invoke with some javascript that looks like this:
function downloadpdf(url)
{
var pdfWindow = window.open( url
,'pdf','top=0,left=0,width=1000,height=700,toolbar=no,status=no,scrollbars=yes,resizable=yes,menubar=no');
}
The application invokes a mix of html and servlet requests beforehand.
But the response to the static PDF always works regardless of when it is
called
Regards
Roger
Gabe Wong wrote:
Roger Parkinson wrote:
I am trying to deliver some PDFs to the browser using my tomcat
application. It works, but not always under SSL and IE.
One file is a static PDF and it lives inside my war file. That works
just fine. The file is accessed using a url like
/myapp/web/myfile.pdf and that always delivers the file.
Other files are generated by the app and live in a configured
directory. They are delivered through a servlet that looks like this:
String mimeType = sc.getMimeType(filename);
FileHelper helper = new FileHelper();
InputStream in = helper.fetch(filename, m_dir);
response.setContentType(mimeType);
response.setContentLength(10115);
response.addHeader("ETag","W/\"963288-1194247031062");
OutputStream out = response.getOutputStream();
byte[] buf = new byte[1024];
int count = 0;
while ((count = in.read(buf)) >= 0)
{
out.write(buf, 0, count);
}
in.close();
out.close();
So apart from some minor fiddling with the contentType etc I don't do
very much. This works fine outside of SSL and it also works fine with
SSL and Firefox, but not SSL+IE.
Thinking it was a problem with headers I did some research and found
a lot of stuff about setting no cache etc. Tried it and it nothing
made any difference (except that I managed to break it). I have taken
all those out because the static file, the one I mentioned at first,
is delivering okay to IE over SSL so I don't believe there is a
problem at the IE end, or not one that cannot be overcome by getting
my response right at the server end.
I used TCPMonitor to sniff the headers using non-SSL and found that
the static file has this response:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
ETag: W/"963288-1194247031062"
Last-Modified: Mon, 05 Nov 2007 07:17:11 GMT
Content-Type: application/pdf
Content-Length: 963288
Date: Wed, 07 Nov 2007 04:54:39 GMT
... pdf file follows
So there doesn't seem to be too much going on there.
When I respond to the request for the dynamic file it looks like this:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 12:00:00 NZST
ETag: W/"963288-1194247031062
Content-Type: application/pdf
Content-Length: 10115
Date: Wed, 07 Nov 2007 05:32:02 GMT
...pdf file follows.
I am getting some cache headers added for free otherwise there is no
difference in the request.
Of course those headers may be making all the difference because IE's
message is 'cannot write the file to cache' which is a bit odd
because we've explicitly told it not to here.
Searching the web on this has a number of answers that suggest adding
those no-cache headers anyway.
So, does anyone know what I need to do to make the two responses
enough the same to stop IE complaining?
I am aware that I have faked the ETag and the length of the file and
that I need to do something smarter there, but I'll do that when it
starts working.
Version info: Tomcat 5.5, Java 1.5, WinXP SP2
Are you calling the dynamic PDF URL directly? For instance typing in
the URL directly in the browser?
The reason I am asking, is that for mixed responses from SSL requests,
IE puts up a warning, whereas FF does not.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: serving files through SSL
> From: Roger Parkinson [mailto:[EMAIL PROTECTED] > Subject: serving files through SSL > > I am trying to deliver some PDFs to the browser using my tomcat > application. It works, but not always under SSL and IE. This is a known problem with IE. A search of the archives (http://marc.info/?l=tomcat-user) for "pdf cache" turns up numerous hits, including this one: http://marc.info/?l=tomcat-user&m=108431336725309&w=2 - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: serving files through SSL
Roger Parkinson wrote:
In both cases the URL is invoke with some javascript that looks like
this:
function downloadpdf(url)
{
var pdfWindow = window.open( url
,'pdf','top=0,left=0,width=1000,height=700,toolbar=no,status=no,scrollbars=yes,resizable=yes,menubar=no');
}
The application invokes a mix of html and servlet requests beforehand.
But the response to the static PDF always works regardless of when it
is called
Regards
Roger
For further clarification, what exactly is the result when the dynamic
PDF over SSL fails to work? blank page? Error? etc.
--
Regards
Gabe Wong
NGASI AppServer Manager
Application server installation and configuration AUTOMATION
http://www.ngasi.com
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: serving files through SSL
I'm opening the PDF in a new window (as the javascript shows) so what I
see for the dynamic pdf is:
1) the new window (empty)
2) the download progress dialog
3) an error dialog referring the file name with the message 'cannot
write the file to the cache'
On the static PDF I don't see 2 or 3 and the new window has the PDF
displayed.
(I' using the terms dynamic and static as referred to in my initial
question, ie static is the PDF in the war file that always works and
dynamic is the one fetched from outside the war file by a servlet and
this is the one with the problem).
I did search on that cache message and all the solutions told me to
either upgrade my browser from 5.5 (I'm using 6), change the browser
config, or set the cache headers that seem to be already set. It was
when I realised that the static PDF was always just fine that I
concluded that the problem did not need to be solved at the browser end.
Thanks for your help
Roger
Gabe Wong wrote:
Roger Parkinson wrote:
In both cases the URL is invoke with some javascript that looks like
this:
function downloadpdf(url)
{
var pdfWindow = window.open( url
,'pdf','top=0,left=0,width=1000,height=700,toolbar=no,status=no,scrollbars=yes,resizable=yes,menubar=no');
}
The application invokes a mix of html and servlet requests beforehand.
But the response to the static PDF always works regardless of when it
is called
Regards
Roger
For further clarification, what exactly is the result when the dynamic
PDF over SSL fails to work? blank page? Error? etc.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: serving files through SSL
Roger Parkinson wrote:
I'm opening the PDF in a new window (as the javascript shows) so what
I see for the dynamic pdf is:
1) the new window (empty)
2) the download progress dialog
3) an error dialog referring the file name with the message 'cannot
write the file to the cache'
On the static PDF I don't see 2 or 3 and the new window has the PDF
displayed.
(I' using the terms dynamic and static as referred to in my initial
question, ie static is the PDF in the war file that always works and
dynamic is the one fetched from outside the war file by a servlet and
this is the one with the problem).
I did search on that cache message and all the solutions told me to
either upgrade my browser from 5.5 (I'm using 6), change the browser
config, or set the cache headers that seem to be already set. It was
when I realised that the static PDF was always just fine that I
concluded that the problem did not need to be solved at the browser end.
1)response.setContentLength(10115);
Is 10115 a hard coded number or just there as an illustration. If it is
hard coded then the content length should be set to the
correct value.
2) response.addHeader("ETag","W/\"963288-1194247031062");
Perhaps the missing \" at the end could be a problem?
--
Regards
Gabe Wong
NGASI AppServer Manager
Application server installation and configuration AUTOMATION
http://www.ngasi.com
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: serving files through SSL
I obviously did not look hard enough in the right places, sorry.
That worked. Specifically:
response.setHeader("Pragma", "cache");
response.setHeader("Cache-Control", "cache");
fixed it.
Thanks for the help.
Roger
Caldarale, Charles R wrote:
From: Roger Parkinson [mailto:[EMAIL PROTECTED]
Subject: Re: serving files through SSL
I've identified that the cache headers are being set by
default on the dynamic file. I don't know that they are
the issue but it is the one difference I can spot.
As you've been told before, it definitely is the issue. To repeat:
This is a known problem with IE. A search of the archives
(http://marc.info/?l=tomcat-user) for "pdf cache" turns up numerous
hits, including this one:
http://marc.info/?l=tomcat-user&m=108431336725309&w=2
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: serving files through SSL
Gabe:
1) response.setContentLength(10115);
Yep, hard coded value figured by checking the length of my test pdf file
manually. I believe it is correct. I don't want to add the code that
would figure the length unless I have some evidence that it makes any
difference and it hasn't yet.
2) I changed the ETag to add the extra quote but that made no
difference. I believe that the ETag is just a semi-random string ('semi'
meaning it is the same value for the same file but otherwise randomly
generated). So the actual content should make no difference.
I'm still looking for the difference between the response for the static
file and the response for the dynamic file. I've identified that the
cache headers are being set by default on the dynamic file. Is there a
way to turn these off? I don't know that they are the issue but it is
the one difference I can spot.
Thanks
Roger
Gabe Wong wrote:
Roger Parkinson wrote:
I'm opening the PDF in a new window (as the javascript shows) so what
I see for the dynamic pdf is:
1) the new window (empty)
2) the download progress dialog
3) an error dialog referring the file name with the message 'cannot
write the file to the cache'
On the static PDF I don't see 2 or 3 and the new window has the PDF
displayed.
(I' using the terms dynamic and static as referred to in my initial
question, ie static is the PDF in the war file that always works and
dynamic is the one fetched from outside the war file by a servlet and
this is the one with the problem).
I did search on that cache message and all the solutions told me to
either upgrade my browser from 5.5 (I'm using 6), change the browser
config, or set the cache headers that seem to be already set. It was
when I realised that the static PDF was always just fine that I
concluded that the problem did not need to be solved at the browser end.
1)response.setContentLength(10115);
Is 10115 a hard coded number or just there as an illustration. If it
is hard coded then the content length should be set to the
correct value.
2) response.addHeader("ETag","W/\"963288-1194247031062");
Perhaps the missing \" at the end could be a problem?
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: serving files through SSL
> From: Roger Parkinson [mailto:[EMAIL PROTECTED] > Subject: Re: serving files through SSL > > I've identified that the cache headers are being set by > default on the dynamic file. I don't know that they are > the issue but it is the one difference I can spot. As you've been told before, it definitely is the issue. To repeat: This is a known problem with IE. A search of the archives (http://marc.info/?l=tomcat-user) for "pdf cache" turns up numerous hits, including this one: http://marc.info/?l=tomcat-user&m=108431336725309&w=2 - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
