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-userm=108431336725309w=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
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
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]
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: [tomcat]How to decrypt the DIGEST authentication?
Think about it the other way around. User types cleartext password, tomcat's authentication digests it and then compares with what is on the database. So when they change the password you need to capture the password in cleartext, digest it yourself, then store it. You don't need to decrypt it, you actually need to ENCRYPT (ie digest) it. take a look at: http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html specifically: If you are writing an application that needs to calculate digested passwords dynamically, call the static |Digest()| method of the |org.apache.catalina.realm.RealmBase| class, passing the cleartext password and the digest algorithm name as arguments. This method will return the digested password. Roger zhongliang zhang wrote: Hi,everyone, I got a problem with the DIGEST authentication. I configured my web.xml as followed: security-constraint web-resource-collection web-resource-nameapp/web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint role-namepoweruser/role-name /auth-constraint /security-constraint login-config auth-methodDIGEST/auth-method realm-nameapp/realm-name /login-config So,if anybody try to access my app,he needs to input his username and password,while the username and password are stored in the Oracle database,not configured in the tomcat-users.xml file which located at $tomcat_home/conf/ directory. I can not configure it in the tomcat-users.xml for the app has an function of make a new user. Is there anyway to solve this problem? P.S. I tried to solve it by coding in my program,like adding the following code to set the response's status to ask for DIGEST authentication. ((HttpServletResponse) response).setStatus(HttpServletResponse.SC_UNAUTHORIZED); But I do not get a way to decryt the DIGEST information. Any advice will be appreciated! thanks. _ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx - 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: Help with Tomcat IIS
We do it because the IIS is already active on the existing server and it is running a bunch of other stuff we don't want to stop (eg MS Exchange). So we cannot have tomcat take over handling port 80 requests. It works fine, though. Roger Jacob Rhoden wrote: Propes, Barry L wrote: there's lots of people who combine the two -- I currently am, because our UNIX support group has not made the environment compatible for or with Tomcat! Sounds like you and I have the same employer (: But seriously, I am trying to work out the pro's and cons of standalone mode. I am wondering why you put IIS in front of tomcat? Does IIS provide other services apart from tomcat, or is there a specific reason? Best Regards, Jacob - 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: tomcat hang/freeze under windows
Useful stuff, thanks. We don't use any filters in the app, but we do have a db. I'll get them to check it out for deadlocks and get a stacktrace. Still a puzzle why a little demo setup gives this and the live apps don't. It will be interesting when we know. Anyway, good general approach advice. Just what I asked for, thanks. R David Delbecq wrote: Looks like a deadlock occuring at your db. You probably have a filter that applies to each request and is deadlocking in some way. The reason you can still reach the login page is that login page is served by tomcat without getting through the filters. The best way, if you have remote access to app, is to get the jvm to issue a stacktrace. On windows, to do this, you have to hit ctrl-break on console running jvm. An alternate way could be to quickly develop a test war that have one servlet that issues Thread.getAllStackTraces() (java 5) on demand. With a stacktrace, you will know exactly where you http thread is waiting :) En l'instant précis du 28/08/07 23:44, Roger Parkinson s'exprimait en ces termes: Sorry this is question is so terse, but general approach kind of help would be very welcome. I get to the login page every time, but after that there's no response. Seems to be nothing relevant in the logs. The machine is remote from me and in a 12 hours different timezone (yawn...zzz) so getting access to local staff is a challenge. Hence the vagueness (apologies again). Restarting tomcat everything comes right for a while, works perfectly, then... freeze. What we are doing is deploying a pair of war files that are known to be running really well elsewhere (ie on my dev env plus two live sites). There are config options in the apps (there are also config options in tomcat that might be screwed too, still checking that). So I don't think it is the app itself. Actually we don't seem to be getting to the app once it freezes except for the login page. I'm using form based login (is that right term? throws up a JSP page with a user/password prompt if you're not logged in, then lets you proceed). Realm is through JDBC to SQLServer. O/s: windows 2000 Java: jdk1.5.0_11 Tomcat 5.5.7 Thanks for any 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] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
tomcat hang/freeze under windows
Sorry this is question is so terse, but general approach kind of help would be very welcome. I get to the login page every time, but after that there's no response. Seems to be nothing relevant in the logs. The machine is remote from me and in a 12 hours different timezone (yawn...zzz) so getting access to local staff is a challenge. Hence the vagueness (apologies again). Restarting tomcat everything comes right for a while, works perfectly, then... freeze. What we are doing is deploying a pair of war files that are known to be running really well elsewhere (ie on my dev env plus two live sites). There are config options in the apps (there are also config options in tomcat that might be screwed too, still checking that). So I don't think it is the app itself. Actually we don't seem to be getting to the app once it freezes except for the login page. I'm using form based login (is that right term? throws up a JSP page with a user/password prompt if you're not logged in, then lets you proceed). Realm is through JDBC to SQLServer. O/s: windows 2000 Java: jdk1.5.0_11 Tomcat 5.5.7 Thanks for any 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]
I want to Redirect to a different app
I have an app running in Tomcat and it works fine. Let's say it is called Demo. I want to leave that instance of the app running just as it is. But I want to be able to do this: http://www.mydomain.com/Testapp Testapp does not exist. I want these requests to invoke Demo, not a second instance of Demo called Testapp, but actually Demo itself. I've looked around for a way to do this but I'm starting to think it cannot be done so time to ask. Configuration is IIS talking to Tomcat 5.5 Thanks Roger -- /Roger Parkinson Mob +64 21 508 792 / - 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: [Fwd: static fields suddenly started sharing]
Thanks for the suggestions, guys. This has been a tricky one to work
through but I think I have the answer - kind of.
A number of people responded with help for which I am grateful (think:
2am and I'm all alone and it has to be fixed by morning, it is so nice
to see a helpful message come through).
What I thought I was seeing was the static fields suddenly being shared
between two apps. I got reports of errors from the live site (to which I
have no direct access) and I reproduced a similar problem on my dev
environment. When I looked deeper I found the statics were shared
between the two apps so I concluded the same thing was happening on the
live site. It certainly explained what they reported from the live site.
But two different things were happening.
On my dev system I run tomcat under eclipse, using the plugin. It has
always worked fine. I recently started using ivy in my eclipse projects
and that seems to do something odd to the class loader which is what I
was seeing.
Filip Hanlik suggested I use this code to see how the classloader was
loading:
ClassLoader parent = this.getClass().getClassLoader();
while ( parent != null ) {
if (parent instance of URLClassLoader) {
//print URLs using getURLS() method
parent = parent.getParent();
}
I put a variation of this into my contextlisterner classes and it showed
this (edited for brevity)
10-05-2007 20:45:58 parent=org.apache.catalina.loader.WebappClassLoader
10-05-2007 20:45:58 file:/C:/projects/Hermes/HermesAdmin/WEB-INF/classes/
10-05-2007 20:45:58
file:/C:/projects/Hermes/HermesAdmin/WEB-INF/lib/HermesServer.jar
10-05-2007 20:45:58
file:/C:/projects/Hermes/HermesAdmin/WEB-INF/lib/MaduraApplet-2.0.jar
10-05-2007 20:45:58
file:/C:/projects/Hermes/HermesAdmin/WEB-INF/lib/MaduraServer-2.0.jar
This is the relevant library
10-05-2007 20:45:58 parent=org.apache.catalina.loader.StandardClassLoader
10-05-2007 20:45:58 file:C:/Program Files/Apache Group/Tomcat
4.1/shared/classes/
...
10-05-2007 20:45:58 parent=org.apache.catalina.loader.StandardClassLoader
10-05-2007 20:45:58 file:C:/Program Files/Apache Group/Tomcat
4.1/common/classes/
...
10-05-2007 20:45:58 parent=sun.misc.Launcher$AppClassLoader
10-05-2007 20:45:58 file:/C:/projects/Hermes/HermesServer/classes/
10-05-2007 20:45:58 file:/C:/eclipsev32/plugins/org.junit_3.8.1/junit.jar
10-05-2007 20:45:58
file:/C:/Program%20Files/Apache%20Group/Tomcat%204.1/common/lib/servlet.jar
...
10-05-2007 20:45:58
file:/C:/projects/ivy_resources_madura/ivy_cache/senanque/Madura/jars/MaduraServer-2.0.jar
and here it is again !!
10-05-2007 20:45:58
file:/C:/projects/ivy_resources_madura/ivy_cache/senanque/Madura/jars/MaduraApplet-2.0.jar
...
10-05-2007 20:45:58
file:/C:/projects/ivy_resources_madura/ivy_cache/apache/xerces/jars/xerces-2.0.2.jar
10-05-2007 20:45:58
file:/C:/Program%20Files/Apache%20Group/Tomcat%204.1/bin/bootstrap.jar
10-05-2007 20:45:58 file:/C:/j2sdk1.4.2_11/lib/tools.jar
10-05-2007 20:45:58 parent=sun.misc.Launcher$ExtClassLoader
10-05-2007 20:45:58 file:/C:/j2sdk1.4.2_11/jre/lib/ext/dnsns.jar
10-05-2007 20:45:58 file:/C:/j2sdk1.4.2_11/jre/lib/ext/ldapsec.jar
10-05-2007 20:45:58 file:/C:/j2sdk1.4.2_11/jre/lib/ext/localedata.jar
10-05-2007 20:45:58 file:/C:/j2sdk1.4.2_11/jre/lib/ext/sunjce_provider.jar
So the problem is that the ivy libraries are loading too early. I don't
see a way to control this from the eclipse UI but it is no problem to
test the apps one at a time. This might help someone else though.
I tried it running stand-alone on the tomcat 5.5 system on my dev
machine and thought I reproduced the error but I cannot now so I will
put that down to late night brain fade.
The live site has mysteriously righted itself. The only thing I know
they did there was to clear the app directories in webapps and restart
the server. It is just possible that they were doing something
ridiculous and not telling me, they aren't very used to tomcat. The most
likely scenario was that they had managed to get two instances of it
running and the phantom application was locking the real one. I'm
getting too specific to my app here, which is not useful, so I'll stop.
Anyway, thanks again for the help. I've mentioned Filip but the
responses from Christopher Schultz and Johnny Kewl were very welcome
too. Oh, and Christopher asked which library I was using. It isn't one
you'd know, a home grown framework used for internal projects.
Regards
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]
[Fwd: static fields suddenly started sharing]
I have two different applications and they both make use of a common jar library. The common library has several static fields. Up until last week the static fields in one application never saw the static fields in the other but I changed something and suddenly they do. All the advice I've found through searching the web suggests this cannot happen because the two apps use different class loaders. But it definitely is happening. I'm getting it on Tomcat 4.1 and 5.5 (my two live platforms). I am trying to figure out what I changed to make this happen because it is causing me problems. The changes I made were a restructure, shifting things around into different folders in my eclipse project, but the same jar files are in WEB-INF/lib as there always were. Can anyone suggest where I should be looking? I'm wondering if I am managing to call something I shouldn't too early in the application initialisation. Each of the apps has a context listener that does some stuff on startup of the app (including initialising some statics), but they haven't changed since it was working. I still have the older structure and it still works, and I can't see any relevant changes, Thanks for any 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]
