کد:
http://blogs.technet.com/isablog/archive/2009/11/21/unable-to-download-an-office-file-from-a-web-server-published-through-isa-server-2006.aspx
1. Introduction

Consider a scenario where ISA Server 2006 is configured to publish a simple web site using HTTPS and within this site there is a link to download a Microsoft Word file. When external users try to download the file they receive the initial window with open or save file options as shown below:



After clicking Save the following error message appears:



The web server was listening on HTTP and an internal user connecting to the web server directly over HTTP was able to download this file. . This problem was happening on all versions of Internet Explorer regardless of the client OS platform (Windows XP, Vista and Windows 7).

2. Gathering more Data

The rule worked for the most part, only this specific condition (downloading office documents) was failing. From an ISA Server perspective, it’s always good in cases like these to get an ISA Data Packager in repro mode using Web Proxy and Web Publishing scenario. In this case it was also important to get a Network Monitor trace from the client workstation and IIS logs from the web server. This way we had the entire communication chain.

3. Analyzing

From an ISA Server perspective there were no errors in traces and live logging was also clear as shown below:
The Web Server logs also appear clear and according to netmon traces the content was transferred from the Web Server to the ISA Server:

ISA Server sends the GET request to the file:
کد:
 10.20.20.2  10.20.20.25 HTTP  HTTP:Request, GET /mydoc.asp

Web Server answers the request with the file:
کد:
10.20.20.25 10.20.20.2  HTTP  HTTP:Response, HTTP/1.1, Status Code = 200, URL: /mydoc.asp
 - Http: Response, HTTP/1.1, Status Code = 200, URL: /mydoc.asp 
     ProtocolVersion: HTTP/1.1
     StatusCode: 200, Ok
     Reason: OK
     Date:  Fri, 20 Nov 2009 21:20:28 GMT
     Server:  Microsoft-IIS/6.0
     XPoweredBy:  ASP.NET
     Cache-control:  no-cache
     ContentLength:  38021
   + ContentType:  application/msword
     Cache-control:  private
     HeaderEnd: CRLF
   - payload: HttpContentType =  application/msword
      HTTPPayloadLine: 
      HTTPPayloadLine:



IIS Logs from the Web Server also shows that the content was correctly answered:
کد:
2009-11-20 21:20:28 W3SVC1 10.20.20.25 GET /mydoc.asp - 82 - 10.20.20.2 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+.NET+CLR+2.0.50727) 200 0 0

At this point we know that client sends the request, ISA correctly sends the request back to the web server which correctly provides the content to ISA. On the client side, Netmon just showed the encrypted conversation. In order to see what was really happening on the client side, we used HTTP Watch and there we could see that the actual content was already local as you can see in the figure below:



4. Resolution

The problem was related to the following header in the response from the web server:

کد:
10.20.20.25 10.20.20.2  HTTP  HTTP:Response, HTTP/1.1, Status Code = 200, URL: /mydoc.asp
 - Http: Response, HTTP/1.1, Status Code = 200, URL: /mydoc.asp 
     ProtocolVersion: HTTP/1.1
     StatusCode: 200, Ok
     Reason: OK
     Date:  Fri, 20 Nov 2009 21:20:28 GMT
     Server:  Microsoft-IIS/6.0
     XPoweredBy:  ASP.NET
     Cache-control:  no-cache
     ContentLength:  38021
   + ContentType:  application/msword
     Cache-control:  private
     HeaderEnd: CRLF
   - payload: HttpContentType =  application/msword
      HTTPPayloadLine: 
      HTTPPayloadLine:



Here it is the explanation why it was failing:

“In order for Internet Explorer to open documents in Office (or any out-of-process, ActiveX document server), Internet Explorer must save the file to the local cache directory and ask the associated application to load the file by using IPersistFile::Load. If the file is not stored to disk, this operation fails.
When Internet Explorer communicates with a secure Web site through SSL, Internet Explorer enforces any no-cache request. If the header or headers are present, Internet Explorer does not cache the file. Consequently, Office cannot open the file.”
From http://support.microsoft.com/kb/316431

Although this article says it applies to IE 5 and IE6, this issue happened on IE7 and IE8. This is an expected behavior and in order to fix this you will need to follow the recommendation from KB316431. The reason why it was working internally for all users is because internally the access to this web server was using HTTP and this problem just happens when using SSL. Once more ISA was not guilty , it was only doing what the web server was asking it to do.

Author
Yuri Diogenes
Sr. Security Support Escalation Engineer
Microsoft CSS Forefront Edge Team

Technical Reviewer
Mohit Kumar
Sr. Security Support Escalation Engineer
Microsoft CSS Forefront Edge Team




موضوعات مشابه: