Re: Download via Componnt with IE SP2 and SSL
Re: Download via Componnt with IE SP2 and SSL
- Subject: Re: Download via Componnt with IE SP2 and SSL
- From: Mark Edwards <email@hidden>
- Date: Tue, 21 Dec 2004 10:09:56 +1100
I should have also mentioned that we've found that the order of setting
headers in the response seems to be important for some browsers. It
doesn't make a lot of sense, but if we re-order the response.set...
code below it doesn't work as well.
Regards,
Mark
On 21 Dec 2004, at 9:58, Mark Edwards wrote:
We've found that the following code snippet works for most downloads
for most browsers, via SSL or not. This is assuming that you have a
fileName (String), a mimeType (String), and a document - data
(NSData). This is how we usually do dynamic file downloads. Hope this
might help someone.
public void appendToResponse(WOResponse response, WOContext
context) {
super.appendToResponse(response, context);
response.disableClientCaching();
response.removeHeadersForKey("Cache-Control");
response.removeHeadersForKey("pragma");
response.setHeader(mimeType, "content-type");
response.setHeader("attachment; filename=\"" + fileName +
"\"", "content-disposition");
response.setContent(data);
}
Regards,
Mark
On 21 Dec 2004, at 8:47, Chuck Hill wrote:
Yeah, IE and SSL and downloads used by an external app are a problem.
One of the things that it does is to "write" the download to the FS
so that the external app can use it. But another part of IE prevents
the write due to the no cache settings. At least that is what I
recall of the "display" PDF over HTTPS problem I was fighting with a
while back. The solution (posted I think on www.wodev.com) is to
alter the headers so that caching is permitted. This reduces the
security a bit (leaves the download on the local filesystem) but at
least it makes the app usable.
Setting the headers should work, depending on where you set them.
What code are you setting then in? Have a look at www.wodev.com for
code.
Chuck
On Dec 20, 2004, at 1:18 PM, Nick Pilch wrote:
Good suggestion, Chuck. I did that and I see the difference below in
the headers. However, I have a theory. From the pause I see in IE
and the network traffic it produces, I think it may be requesting
the file twice. And the second request fails because the resource
has expired. I tried explicitly setting the "expires" and "Expires"
headers in the request, but that doesn't seem to alter the headers!
I've had the problem before of various browsers requesting resources
twice...
SENDING STREAM (doesn't work)
HTTP/1.1 200 Apple
Date: Mon, 20 Dec 2004 20:13:13 GMT
Server: Apache/1.3.33 (Darwin) mod_ssl/2.8.22 OpenSSL/0.9.7b
DAV/1.0.3
Cache-Control: max-age=60
Expires: Mon, 20 Dec 2004 20:14:13 GMT
cache-control: private
cache-control: no-cache
cache-control: no-store
cache-control: must-revalidate
cache-control: max-age=0
content-disposition: attachment; filename="client-prod.zip"
expires: Mon, 20-Dec-2004 20:05:00 GMT
pragma: no-cache
content-length: 15967690
Connection: close
Content-Type: application/zip
DIRECT LINK TO FILE (works)
HTTP/1.1 200 OK
Date: Mon, 20 Dec 2004 20:38:26 GMT
Server: Apache/1.3.33 (Darwin) mod_ssl/2.8.22 OpenSSL/0.9.7b
DAV/1.0.3
Cache-Control: max-age=60
Expires: Mon, 20 Dec 2004 20:39:26 GMT
Last-Modified: Wed, 15 Dec 2004 10:10:46 GMT
ETag: "c7478b-f3a5a1-41c00da6"
Accept-Ranges: bytes
Content-Length: 15967649
Connection: close
Content-Type: application/zip
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden