Use case: user clicks the link on a webpage - boom! load of files sitting in his folder.
I tried to pack files using multipart/mixed message, but it seems to work only for Firefox
This is how my response looks like:
HTTP/1.0 200 OK
Connection: close
Date: Wed, 24 Jun 2009 23:41:40 GMT
Content-Type: multipart/mixed;boundary=AMZ90RFX875LKMFasdf09DDFF3
Client-Date: Wed, 24 Jun 2009 23:41:40 GMT
Client-Peer: 127.0.0.1:3000
Client-Response-Num: 1
MIME-Version: 1.0
Status: 200
--AMZ90RFX875LKMFasdf09DDFF3
Content-type: image/jpeg
Content-transfer-encoding: binary
Content-disposition: attachment; filename="001.jpg"
<< here goes binary data >>--AMZ90RFX875LKMFasdf09DDFF3
Content-type: image/jpeg
Content-transfer-encoding: binary
Content-disposition: attachment; filename="002.jpg"
<< here goes binary data >>--AMZ90RFX875LKMFasdf09DDFF3
--AMZ90RFX875LKMFasdf09DDFF3--
Thank you
P.S. No, zipping files is not an option
Zipping is the only option that will have consistent result on all browsers. If it's not an option because you don't know zips can be generated dynamically, well, they can. If it's not an option because you have a grudge against zip files, well..
MIME/multipart is for email messages and/or POST transmission to the HTTP server. It was never intended to be received and parsed on the client side of a HTTP transaction. Some browsers do implement it, some others don't.
As another alternative, you could have a JavaScript script opening windows downloading the individual files. Or a Java Applet (requires Java Runtimes on the machines, if it's an enterprise application, that shouldn't be a problem [as the NetAdmin can deploy it on the workstations]) that would download the files in a directory of the user's choice.
Remember doing this >10 years ago in the netscape 4 days. It used boundaries like what your doing and didn't work at all with other browsers at that time.
While it does not answer your question HTTP 1.1 supports request pipelining so that at least the same TCP connection can be reused to download multiple images.
You can use base64 encoding to embed an (very small) image into a HTML document, however from a browser/server standpoint, you're technically still sending only 1 document. Maybe this is what you intend to do?
Embedd Images into HTML using Base64
EDIT: i just realized that most methods i found in my google search only support firefox, and not iE.
You could make a json with multiple data urls.
Eg:
{
"stamp.png": "data:image/png;base64,...",
"document.pdf": "data:application/pdf;base64,..."
}
(extending trinalbadger587's answer)
You could return an html with multiple clickable, downloadable, inplace data links:
<html>
<body>
<a download="yourCoolFilename.png" href="data:image/png;base64,...">PNG</a>
<a download="theFileGetsSavedWithThisName.pdf" href="data:application/pdf;base64,...">PDF</a>
</body>
</html>
Related
I have a classic ASP application with a page that will export a CSV file. It works in all browsers except Internet Explorer (IE). It worked in IE before the company updated everyone's computer to Windows 8 and IE10. I've tried compatibility mode on and off and I have used F12 to change the Browser Mode and Document Mode. I have the following code to set headers and etc...
Response.ContentType = "application/csv"
Response.AddHeader "Cache-Control", "no-cache"
Response.AddHeader "Content-Disposition", "attachment; filename=myfilename.csv"
I've also tried Response.Content-Type="text/csv" with no success. I've been banging Google hard for a day or two looking for resolutions but cannot find any help. Does anyone have some suggestions?
EDIT: Below is some more information I've pulled from Fiddler about the headers. Also, I should have mentioned that Fiddler shows the data is being written to the Response.
HTTP/1.1 200 OK
Cache-Control: no-store, no-cache,private
Content-Type: text/csv
Server: Microsoft-IIS/7.5
Content-Disposition: attachment; filename=somefilename.csv
Persistent-Auth: true
X-Powered-By: ASP.NET
Date: Thu, 14 Aug 2014 17:41:56 GMT
Connection: close
UPDATE:
I've been able to determine the issue is occurring due to the fact I am uploading a file and then trying to export file in the same Request/Response cycle. When I submit the data manually (via hidden fields) and not upload the file, the download works. So now I am trying to figure out a fix for this situation.
RESOLVED
It turns out to be an Internet Explore plus Windows Update issue. See the link below for more information.
Problem Description
I'm trying to dissect a single HTTP request made to some website --> www.somesite.com ... If I understand correctly, the browser will issue a GET request as such:
GET http://www.somesite.com/index.html HTTP/1.1
Ultimately the server will send a response as such:
HTTP/1.1 200 OK
Date: Fri, 21 Feb 2014 10:00:00 GMT
Content-Type: text/html
Content-Length: 1354
<html>
<body>
.
.
.
</body>
</html>
Assuming this index.html contains images and css and javascript assets, if the response was simply 200 OK, how does the client know to go back and fetch the other assets? Meaning, how does the client know that index.html has been served in its entirety when all it did was simply issue the first GET request?
Well, it is hard to understand, what you want to know. The first get will either return data or redirect elsewhere. When browser receives HTML page, it will parse it to element tree and saves links to download (css, js, images). It downloads them and if they contain references to other resources (js, css, images), it will download them as well. When the queue is empty, browser finishes downloading.
Does this high level description answear your question?
I'm trying to download an excel file (generated dynamically using C#\ASP.NET) and I get the IE10 View Downloads dialog when I click "Open" it says "abc.xls couldn't be downloaded" error but after clicking "Retry" it opens the .xls file properly in the second try.
When I test this in Firefox or Chrome it works fine.
I think this may explain the strange behaviour:
"Content-Length and Transfer-Encoding Validation in the IE10 Download Manager"
It seems that IE9 beta had introduced content-length and transfer-encoding validation when downloading files, but found it was too problematic since many servers didn't send proper values for these downloads that are processed through code. Apparently they turned it back on in IE10 however and just hoped for the best.
I'd wager that accurate values being sent when the download is started should clear up this problem. Of course, it shouldn't have been a problem to begin with... ai yi yi.
[Edit]
Turns out this problem was related (for me at least) with using Response.Close() and/or Response.End() in code. This article explains why you shouldn't use these 2 methods, and why HttpApplication.CompleteRequest is the method of choice. Changing our Response.End() and Response.Close() instances to HttpApplication.CompleteRequest solved our IE10 download issues. Like magic. Apparently MSDN now discourages use of these 2 methods (despite years of MSDN code examples containing them), and now advocates use of HttpApplication.CompleteRequest instead.
We were always at war with Eurasia...
[/Edit]
I was getting a similar behavior -
After fighting this issue for about 12 hours what worked for me:
Changing response header from
Content-Type: application/application/vnd.ms-excel
To
Content-Type: application/octet-stream
Note that I had another an unmentioned symptom: I was setting
Content-Disposition: attachment; filename="Inventory_10-10-2013.xls"
Despite that setting IE used the file name from the URL (so it said "getInventory couldn't be downloaded" - and it saved the wrongly named file in the downloads folder!).
When I changed the 'Content-Type' IE started honoring the file name from the header.
For the record here are all the response headers that I'm setting:
HTTP/1.1 200 OK
Pragma: Public
Expires: Fri, 11 Oct 2013 16:33:38 GMT
Cache-Control: max-age=1
Content-Disposition: attachment; filename="Inventory_10-10-2013.xls"
Content-Transfer-Encoding: BINARY
Set-Cookie: fileDownload=true; path=/
Content-Type: application/octet-stream;charset=UTF-8
Content-Length: 7680
Date: Thu, 10 Oct 2013 16:33:38 GMT
I have searched regarding this content type,Content-Type: application/vnd.google.safebrowsing-update. though some articles are given on net regarding this type but i still don't understand :S
HTTP/1.0 200 OK
Content-Type: application/vnd.google.safebrowsing-update
X-Content-Type-Options: nosniff
Date: Tue, 16 Dec 2011 05:57:44 GMT
Server: Chunked Update Server
Content-Length: 459
X-XSS-Protection: 1; mode=block
Connection: Keep-Alive
application/ indicates that the content is intended to be opened by a specific application.
vnd. indicates that the MIME-type is defined by a specific vendor. This is useful when creating your own file types for your programs and intend to distribute them online. You can register specific MIME types to open with your program without the possibility of interefering with other opreation.
google. is the vendor in this case.
safebrowsing-update is the specific type of file from Google. The name is self-explanatory.
The content type tells you that it is application-specific (application/) and is an update to Google's Safe Browsing feature.
The Content-Type header, in the general, is to inform a client which parser to use for a server's response to a request. For example, a web browser might use one interface to render an RSS feed, another to render an HTML web page, and a third to display a PDF.
In this case, the reply is said to contain information about a list of web sites considered safe or unsafe by Google.
I have been using Wireshark and I noticed that my plugin seem to track down everything I do. I would like to see what is sending back.
http://dynamic.hotbar.com/dynamic/hotbar/disp/3.0/sitedisp.dll?GetSDF&Dom=usinsuranceonline.com&Path=&SiteVer=0
content looks something like:
Headers:
HTTP/1.1 200 OK Connection: close Date: Thu, 19 May 2011 05:40:29 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET Content-Length: 90 Content-Type: app/x-hotbar-xip20 Expires: 0
Content XIP_2.0|1.SDF|67|70|xŚˇ334‹330±00ąr+-ĪĢ+.-JĢKNĶĻĖÉĢKÕKĪĻ¨3ä ¨Ó¸3©Õ5ār‘qŁ©•åłE)Å\Č#
When I try to open it, it downloads me a sitedisp.dll file which does not say anything. How can I open/decode these type of files?
It seems to connect to IE plugin
If it is a .NET dll, you can see its contents quite easily with Reflector.
http://reflector.red-gate.com/download.aspx?TreatAsUpdate=1
That said, the Hotbar terms of service appear to explicitly say you shall not decompile or reverse engineer the product... The message does appear to be encrypted in some way, as Tony mentioned. Depending on the scheme they used, it may be terribly difficult to see the contents in clear text, and since your not supposed to be reverse engineering it, I vote that you just delete the program from your machine entirely and move on to something else.
sitedisp.dll is a DLL file, which means it's a binary which contains executable code. Opening it will probably not teach you much unless you know Assembler or if it's a .NET DLL, Intermediate Language. The data which is sent back to the server is not going to be part of that DLL.
It looks like that this: xŚˇ334‹330±00ąr+-ĪĢ+.-JĢKNĶĻĖÉĢKÕKĪĻ¨3ä ¨Ó¸3©Õ5ār‘qŁ©•åłE)Å\Č#
could be the data in some encrypted form, however I'm not sure.