No. The content-type should be whatever it is known to be, if you know it. application/octet-stream is defined as “arbitrary binary data” in RFC 2046, and there’s a definite overlap here of it being appropriate for entities whose sole intended purpose is to be saved to disk, and from that point on be outside of … Read more
To indicate to the browser that the file should be viewed in the browser, the HTTP response should include these headers: Content-Type: application/pdf Content-Disposition: inline; filename=”filename.pdf” To have the file downloaded rather than viewed: Content-Type: application/pdf Content-Disposition: attachment; filename=”filename.pdf” The quotes around the filename are required if the filename contains special characters such as filename[1].pdf … Read more
I’m not sure about your exact version, but Chrome has a tab “Network” with several items and when I click on them I can see the headers on the right in a tab. Press F12 on windows or ⌥⌘I on a mac to bring up the Chrome developer tools.
Header names are not case sensitive. From RFC 2616 – “Hypertext Transfer Protocol — HTTP/1.1”, Section 4.2, “Message Headers”: Each header field consists of a name followed by a colon (“:”) and the field value. Field names are case-insensitive. The updating RFC 7230 does not list any changes from RFC 2616 at this part.
public ActionResult Download() { var document = … var cd = new System.Net.Mime.ContentDisposition { // for example foo.bak FileName = document.FileName, // always prompt the user for downloading, set to true if you want // the browser to try to show the file inline Inline = false, }; Response.AppendHeader(“Content-Disposition”, cd.ToString()); return File(document.Data, document.ContentType); } NOTE: … Read more
Sending headers earlier than the normal course may have far reaching consequences. Below are just a few of them that happened to come to my mind at the moment: While current PHP releases may have output buffering on, the actual production servers you will be deploying your code on are far more important than any … Read more
I know this is an old post but it is still very relevant. I have found that modern browsers support rfc5987, which allows utf-8 encoding, percentage encoded (url-encoded). Then Naïve file.txt becomes: Content-Disposition: attachment; filename*=UTF-8”Na%C3%AFve%20file.txt Safari (5) does not support this. Instead you should use the Safari standard of writing the file name directly in … Read more
TL;DR Summary; if you have binary (non-alphanumeric) data (or a significantly sized payload) to transmit, use multipart/form-data. Otherwise, use application/x-www-form-urlencoded. The MIME types you mention are the two Content-Type headers for HTTP POST requests that user-agents (browsers) must support. The purpose of both of those types of requests is to send a list of name/value … Read more
It’s not possible to read the current headers. You could make another request to the same URL and read its headers, but there is no guarantee that the headers are exactly equal to the current. Use the following JavaScript code to get all the HTTP headers by performing a get request: var req = new … Read more
When you make a POST request, you have to encode the data that forms the body of the request in some way. HTML forms provide three methods of encoding. application/x-www-form-urlencoded (the default) multipart/form-data text/plain Work was being done on adding application/json, but that has been abandoned. (Other encodings are possible with HTTP requests generated using … Read more