24

Simply put, I'd like someone to be able to click a link, and get a one-time-use pdf. We have the library to create PDF files, so that's not an issue.

We could generate a link to an aspx page, have that page generate the pdf, save the pdf to the filesystem, and then Response.Redirect to the saved pdf. Then we'd somehow have to keep track of and clean up the PDF file.

Since we don't ever need to keep this data, what I'd like to do instead, if possible, is to have the aspx page generate the pdf, and serve it directly back as a response to the original request. Is this possible?

(In our case, we're using C#, and we want to serve a pdf back, but it seems like any solution would probably work for various .NET languages and returned filetypes.)

Diego C.
  • 2,271
  • 2
  • 20
  • 21
Beska
  • 12,445
  • 14
  • 77
  • 112
  • 3
    Not dupe of the above in any meaning. – nothrow Jan 13 '10 at 15:38
  • (I knew I was going to get a couple people say to close as dupe, pointing to that type of question...which is why I included the second sentence. I should have made it the first sentence. :) ) – Beska Jan 13 '10 at 15:40
  • Related: http://stackoverflow.com/questions/1038707/cant-display-pdf-from-https-in-ie-8-on-64-bit-vista/1112202#1112202 – lance Jan 13 '10 at 15:37

2 Answers2

45

Assuming you can get a byte[] representing your PDF:

Response.Clear();
Response.ContentType = "application/pdf";
Response.AddHeader("Content-Disposition",
    "attachment;filename=\"FileName.pdf\"");

Response.BinaryWrite(yourPdfAsByteArray);

Response.Flush();

Response.End();
Justin Niessner
  • 242,243
  • 40
  • 408
  • 536
  • 1
    This looks very promising...I figured it would be something along these lines, but don't have the background to know the details. Thanks for the response; I'll try this tact. – Beska Jan 13 '10 at 15:38
  • This nailed the problem precisely. Thanks! – Beska Jan 13 '10 at 16:17
  • One related question (maybe I should open a seperate question, but it's tightly related to this answer...) Why the Response.Flush()? When we have that line in there, and someone closes the browser after making the request, we get an error: "The remote host closed the connection." If we leave that line out, no error, and everything *seems* to work. Reading the MSDN docs didn't illuminate me on whether this was strictly necessary. Thoughts? – Beska Mar 10 '10 at 18:49
  • A quick look into Reflector says that Response.End() calls Response.Flush() anyway...so maybe it's not explicitly needed. – Justin Niessner Mar 10 '10 at 18:57
2

Look at how HTTP works. The client (=browser) doesn't rely on extensions, it only wants the server to return some metadata along with the document.

Metadata can be added with Response.AddHeader, and one 'metadata line' consists of Name and Value.

Content-Type is the property you are interested in, and the value is MIME type of the data (study: RFC1945 for HTTP headers, google for MIME type).

For ordinal aspx pages (html, ....) the property is 'text/html' (not so trivial, but for this example it is enough.). If you return JPG image, it can have name 'image.gif', but as long as you send 'image/jpeg' in Content-Type, it is processed as JPG image. Content-type for pdf is 'application/pdf'.

The browser will act according to default behaviour, for example, with Adobe plugin, it will display the PDF in it's window, if you don't have any plugin for PDF, it should download the file, etc..

Content-Disposition header says, what you should do with the data. If you want explicitly the client to 'download' some HTML/PDF/whatever, and not display it by default, value 'attachment' is what you want. It should have another parameter, (as suggested by Justin Niessner), which is used in case of something like:

http://server/download.aspx?file=11 -> Content-Disposition: attachment;filename=file.jpg says, how the file should be by default named.

nothrow
  • 15,882
  • 9
  • 57
  • 104