Unable to Download an Office file from a Web Server Published through ISA Server 2006


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


Comments (0)

Skip to main content