| Summary: | Download of MS Office docs from protected areas fail with IE | ||
|---|---|---|---|
| Product: | Tomcat 4 | Reporter: | Martin Hengesbach <martin> |
| Component: | Catalina | Assignee: | Tomcat Developers Mailing List <dev> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | danrodney, vicentesalvador |
| Priority: | P3 | ||
| Version: | 4.0.2 Final | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | All | ||
|
Description
Martin Hengesbach
2002-02-22 10:49:45 UTC
Unfortunately, I can't reproduce this bug. So while I'd like to fix it, I can't do anything without you debugging what in the request / response something might be different which would cause IE to fail. I can confirm this bug on W2000- JDK 1.4, So OS should be all I can't download pdf,doc,xls ... file with IE through an HTTPS+BasicAuth connexion. IE----SSL+Basic Auth------>Apache+mod_jk------------ajp13-------->tomcat4.0.2 I got an error as described in http://support.microsoft.com/default.aspx? scid=kb;EN-US;q196505. This is due to HTTP cache control headers returned by tomcat. When a page is downloaded with an authentication, the HTTP server set cache control headers (Pragma, Cache-Control, Expires) to avoid proxies to cache the page.In such case, this gives something like that : HTTP/1.1 200 OK Content-Type: application/pdf Content-Length: 111219 Date: Tue, 26 Feb 2002 16:20:32 GMT Pragma: No-cache Server: Apache Tomcat/4.0.2 (HTTP/1.1 Connector) Cache-Control: no-cache Last-Modified: Tue, 26 Feb 2002 16:13:27 GMT ETag: "111219-1014740007000" Expires: Thu, 01 Jan 1970 00:00:00 GMT When the page is downloaded through an HTTPS connexions, those cache control headers are not more needed because the document is encrypted ! Through the mod_jk connector (even with JkExtractSSL directive), tomcat always set cache control headers when Authentication is done. I have done some tests with Apache. Cache control headers are not set when using SSL and Authentication and I have no problem with IE to download .pdf, .doc etc ... So, there might be something to correct in the Ajp13 connector... Bye, Not only an AJP13 connector issue. I've tested this with a "non encrypted" connection retrieving a Word document from a protected area and it Fails!!! Hi remy, here are the steps to reproduce the problem: 1. Create a sample Word document and put it on examples/jsp/security/protected/sample.doc 2. Start catalina and get this document: http://localhost/jsp/security/protected/sample.doc 3. Authenticate as tomcat 4. The Open-Save dialog appears. Select open and the document opens on word OK. 5. Change URL to http://localhost/jsp/security/protected/sample.xxx The error page appears 6. Put again the correct URL: http://localhost/jsp/security/protected/sample.doc Sometimes the IE thows and error and others opens the Form login as Word document. This is because catalina tries to re-authenticate the document. Here is the log file that demonstrates this: 127.0.0.1 - - [27/Feb/2002:12:16:28 1000] "GET /jsp/security/protected/sample.doc HTTP/1.1" 404 675 127.0.0.1 - - [27/Feb/2002:12:16:35 1000] "GET /examples/jsp/security/protected/sample.doc HTTP/1.1" 302 654 127.0.0.1 - - [27/Feb/2002:12:16:35 1000] "GET /examples/jsp/security/protected/login.jsp HTTP/1.1" 200 611 127.0.0.1 - - [27/Feb/2002:12:16:40 1000] "POST /examples/jsp/security/protected/j_security_check HTTP/1.1" 302 654 127.0.0.1 - tomcat [27/Feb/2002:12:16:40 1000] "GET /examples/jsp/security/protected/sample.doc HTTP/1.1" 200 19456 127.0.0.1 - - [27/Feb/2002:12:16:43 1000] "OPTIONS /examples/jsp/security/protected HTTP/1.1" 200 - 127.0.0.1 - - [27/Feb/2002:12:16:43 1000] "GET /_vti_inf.html HTTP/1.1" 404 615 127.0.0.1 - - [27/Feb/2002:12:16:43 1000] "POST /_vti_bin/shtml.exe/_vti_rpc HTTP/1.1" 404 657 127.0.0.1 - - [27/Feb/2002:12:16:43 1000] "OPTIONS /examples/jsp/security/protected/sample.doc HTTP/1.1" 200 - 127.0.0.1 - tomcat [27/Feb/2002:12:16:51 1000] "GET /examples/jsp/security/protected/login.jsp HTTP/1.1" 200 611 127.0.0.1 - - [27/Feb/2002:12:16:51 1000] "GET /jsp/security/protected/sample.doc HTTP/1.1" 404 675 127.0.0.1 - - [27/Feb/2002:12:16:58 1000] "GET /jsp/security/protected/sample.doc HTTP/1.1" 404 675 127.0.0.1 - tomcat [27/Feb/2002:12:17:03 1000] "GET /examples/jsp/security/protected/sample.doc HTTP/1.1" 200 19456 127.0.0.1 - - [27/Feb/2002:12:17:05 1000] "OPTIONS /examples/jsp/security/protected HTTP/1.1" 200 - 127.0.0.1 - - [27/Feb/2002:12:17:05 1000] "GET /_vti_inf.html HTTP/1.1" 404 615 127.0.0.1 - - [27/Feb/2002:12:17:05 1000] "POST /_vti_bin/shtml.exe/_vti_rpc HTTP/1.1" 404 657 127.0.0.1 - - [27/Feb/2002:12:17:05 1000] "OPTIONS /examples/jsp/security/protected/sample.doc HTTP/1.1" 200 - 127.0.0.1 - - [27/Feb/2002:12:17:05 1000] "GET /examples/jsp/security/protected/sample.doc HTTP/1.1" 302 654 127.0.0.1 - - [27/Feb/2002:12:17:05 1000] "GET /examples/jsp/security/protected/login.jsp HTTP/1.1" 200 611 127.0.0.1 - tomcat [27/Feb/2002:12:17:37 1000] "GET /examples/jsp/security/protected/tomcat.gif HTTP/1.1" 200 1934 127.0.0.1 - tomcat [27/Feb/2002:12:20:37 1000] "GET /examples/jsp/security/protected/tomcat.xxx HTTP/1.1" 404 675 127.0.0.1 - tomcat [27/Feb/2002:12:24:50 1000] "GET /examples/jsp/security/protected/sample.doc HTTP/1.1" 200 19456 127.0.0.1 - - [27/Feb/2002:12:24:52 1000] "OPTIONS /examples/jsp/security/protected HTTP/1.1" 200 - 127.0.0.1 - - [27/Feb/2002:12:24:52 1000] "GET /_vti_inf.html HTTP/1.1" 404 615 127.0.0.1 - - [27/Feb/2002:12:24:52 1000] "POST /_vti_bin/shtml.exe/_vti_rpc HTTP/1.1" 404 657 127.0.0.1 - - [27/Feb/2002:12:24:52 1000] "OPTIONS /examples/jsp/security/protected/sample.doc HTTP/1.1" 200 - 127.0.0.1 - - [27/Feb/2002:12:24:52 1000] "GET /examples/jsp/security/protected/sample.doc HTTP/1.1" 302 654 127.0.0.1 - - [27/Feb/2002:12:24:52 1000] "GET /examples/jsp/security/protected/login.jsp HTTP/1.1" 200 611 Fine. I'll remove the cache control headers if the connection is secure. Now if somebody could explain to me how this isn't a IE bug, I would be happy (I don't see the problem with setting the cache control headers, even if it's not useful ...). Fixed in both branches. Hi again remy, As you can see in my previous post with test case. This bug is not only for secure (https) connections also occurs with standard http connections. I'seen the cvs post you've made to solve this bug and I'm not sure this will solve the problem. The problem is with authenticate contexts not with secure connections!!!. Please try my sample and verify that it trully works. Well, it's an IE bug in that case, and it won't be fixed. Since IE reissues the request, I don't understand why it's not handling it well the second time. I assume upgrading to a newer IE version would fix the problem. But 4.0.1 works fine with IE 5.5 ;-) and look at the log, it seems like the authenticated context is lost second time we get the file!!! I think we should spend a little more time trying to catch this issue, because IE is very extended browser on the market. I have tested it with IE 5.0, IE 5.5 SP2 and IE 6.0 The error was in every version. So, it might be an IE error but I can't imagine that MS will correct it in the next time... AND, in tomcat 4.0.1 there wasn't the error. So the problem originate from the update from tomcat 4.0.1 to 4.0.2. TC 4.0.1 allowed protected resources to be cached, which is a security problem (any proxy between the client and the server would cache the resource, and could serve the resource to another client). TC 4.0.2 doesn't allow protected resources to be cached. As for the "it seems like the authenticated context is lost second time we get the file!!!": if you correctly resubmit the authentication credentials, it will work. Besides, I don't see anything bad in the logs, except some MS FP junk (GET /_vti_inf.html HTTP/1.1). If you have a problem, the workaround is easy: download the file to your HD, and open it from there, instead of relying on the HTTP redirector IE provides through its fancy OLE 2 embedding. Lastly, "So, it might be an IE error but I can't imagine that MS will correct it in the next time..." is NEVER A GOOD ARGUMENT, esp if it deals with security. If you're not happy with that policy, you should use another vendor. *** Bug 8923 has been marked as a duplicate of this bug. *** |