Friday, April 29, 2011

Classic ASP: posting with content of PDF file to a .NET page

So the problem is half the app is written in classic asp and half is in asp.net. There's a PDF file (in memory) that is generated by classic asp code that I need to share with the .NET half. I thought of saving the PDF to the FS or DB, which I am pretty sure most of you wouldn't recommend because it would need to go through a very slow process of saving to IO, and then I would need to manually clean up after -- unnecessarily creating more bottlenecks and failure points.

I thought of mimicking a post from the classic asp page to .NET by using Server.Transfer or Microsoft.XMLHTTP objects, but neither exactly fits the scenario as I really do want the URL on the client side to be pointing at the .NET aspx page. So is there a simple way to manufacture a POST from classic ASP to a .NET page with a PDF file embedded?

Thanks in advance for any comments or suggestions.

From stackoverflow
  • Your best bet is probably the FS or DB considering the difficulties ASP.NET and ASP interaction. That's my "path of least resistance".

  • Somewhat of a hack, but...

    Create a form in classic ASP with a field that you populate with the data from the PDF file. The action of the form would be the ASP.NET page. Something like:

    <body onload="pdfsenderform.submit()">
        <form name="pdfsenderform" action="pdf.aspx" method="post">
           <input type="hidden" name="pdffiledata" value="<%...output your PDF data here...%>" />
       </form>
    </body>
    

    You might need to encode the binary PDF data prior to writing it to the form field (Base64 or something).

    Haoest : I ended up doing it this way. It takes some extra bandwidth but least maintenance headache.
    Mark Brackett : Ouch...so, instead of writing to disk you're round-tripping it to the client? I can't think of many scenarios where that would be faster....
    squillman : Yeah, never said it was pretty...
  • Just write it to disk, store the filename in a cookie or querystring, and Response.Redirect the user. It's likely to be "fast enough" and much easier than writing a least common denominator State Server accessible over TCP to both of them - which is the only in memory way of doing I can think of.

0 comments:

Post a Comment