Bug: DocumentManager does not emit Content-Disposition header

Question

Good afternoon,
I have a process with an output variable of type Document: this document has a defined filename. When invoking the process, instead of downloading the file with the defined filename, I was receiving a file with a name that looks like an MD5 hash.
The fault for this lies with the DocumentManager application: it does not emit the content disposition header that would suggest to the browser what the real name of the octet-stream is. As such, without this header, the user agent will assume that the file-name is the endpoint name.
The trace of the HTTP exchange is below:
GET http://HOST:8080/rest/services/APP/SERVICE:1.0?q=83
Cache-Control     no-cache, must-revalidate
Date              Wed, 17 Nov 2010 12:54:29 GMT
Pragma            no-cache
Transfer-Encoding chunked
Location          http://HOST:8080/DocumentManager/docm$(NUMBER)/$(HASH)?type=$(TYPE)
X-Powered-By      Servlet/2.5 JSP/2.1
GET http://HOST:8080/DocumentManager/docm$(NUMBER)/$(HASH)?type=$(TYPE)
Date              Wed, 17 Nov 2010 12:54:35 GMT
Transfer-Encoding chunked
Content-Type      application/vnd.ms-excel
X-Powered-By      Servlet/2.5 JSP/2.1
The 2nd HTTP request should have included the specified header, like so:
Content-Disposition: attachment; filename=MyExcel.xls
RFC 2183: The Content-Disposition Header Field
Best regards,

Answer 1

Hi Robert,
thanks for the reply. This is certainly a different aspect of the problem. The HTTP response that serves the dynamic portion (the one with the timestamp) has the response headers:
HTTP/1.1 200 OK
Date: Wed, 21 Jan 2015 18:05:53 GMT
Server: Apache/2.2.29 (Unix)
X-Powered-By: PHP/5.3.29
Cache-Control: max-age=100000, public
Keep-Alive: timeout=3, max=95
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml
So it is marked as cacheable. 
My expectation now is this:
- when clicking the "refresh" link in the markup, there should be no new timestamp. Reason is that the dynamic part should have been cached and I would expect the XSLT engine to use the browser's caching layer when fetching fragments
- when hitting "F5" I would expect a revalidation request to be send to the server (e.g. max-age=0 or if-modified-since). Then the server can revalidate the fragment. In my example case the fragment would be served in any case, so I would expect a
new timestamp
- when hitting "CTRL+F5" I would expect a request with "cache-control: no-cache" that enforces the server side caches to always return new content. I would expect a new timestamp in this case.
What I observe is that:
- Chrome and FF work as expected
- IE (10/11) will always fetch the dynamic fragment, so I will even see a new timestamp when clicking the refresh link. Also the "if-none-match" header in the "F5" case is NOT forwarded to the dynamic fragment (potentially because it is
not cached in the browser at all)
Carsten