How to map the .PDF file extension to the ASP.NET dll

[David]

Should you be able to map a any file extension to the ASP.NET dll and
have it execute ASP.NET script, just like an .aspx page, when it is
requested by a browser. If not, why bother giving us the ability to
create application mappings.

I have an .aspx page that calls an SAP function which returns an
actual PDF to my calling .aspx. My .aspx then returns that PDF result
to the browser.

When a browser requests that .aspx page, if I try to return that PDF
result as a response back to the calling browser, the browser does not
recognize it as a PDF (thus loading up Adobe Acrobat, etc.). This is
even after I have set the content type to "application/pdf".

The browser is smart enough to know that this isn't a typical HTML
page, so it asks me if I want to Open or Save or Cancel this document.
If I click Save, then it tries to save it as an .aspx document, which
I understand, but I do not want to happen. I'd rather it at least try
to save it as a PDF. If I click Open, then it quite naturally tries
to open it as an .aspx page, which means it opens up the PDF results
in Visual Studio, which is also not what I want.

So I was trying to figure out how I can get a browser to request a
file that can dynamically create a PDF using ASP.NET script AND have
the browser know that the response is a PDF and thus, open it up in
Adobe Acrobat.

I am assuming at this point that the only way a an unknown user's
browser can reliably open up a file within Adobe is if it has the
actual PDF extension. I then decided to create a special web
application where I would map the .PDF extension to the ASP.NET dll in
my application mappings. Then, I would rename my webform1.aspx file
to webform1.pdf. Thus, when a browser requested webform1.pdf, my
application would process it as an asp.net page and the end result
being it would return an actual PDF to the browser and the browser
would open it in Adobe Acrobat.

However, it appears that IIS is IGNORING my PDF application mapping
and instead, it is procesing my webform1.pdf as a normal text file,
instead of executing the script within it. I even tried mapping a
neutral file extension, such as .test to the ASP.NET dll, but I got
the same disappointing result.

Does anyone know any way around the application mapping issue? Or
better yet, understands how to deliver an asp.net-dynamically created
PDF back to a browser so that it will open in Adobe Acrobat?

Thanks

 

[dave]

I think I had roughly the same problem when I wrote a web
service to convert tif's to pdf's - the only way I could
return a pdf, even after setting the content type, was to
set the last 4 characters in the url to ".pdf" - it's
stupid but it did the trick.

 

[Craig Deelsnyder [MVP]]

You should be able to do this by setting the content-type appropriately,
then the web browser understands that it is a PDF and will open it. Now
there's two caveats: one, it used to be, the user could set in IE whether
an application such as Adobe should open in IE or in its own window. Don't
know that that is an option anymore.

But more importantly, IE6 does not handling the streaming of PDFs well at
all. The changing content-type throws it for a loop most times. Someone
posted a workaround here a few months ago, but it was rather hokey and
assumed certain performance values.....that said, I link directly to a PDF
now, or redirect to it in the URL, after creating a temp file on my server.
Too many issues with IE...

But if interested, here's a little intro into setting the content-type,
attachment, etc.:

http://www.ondotnet.com/pub/a/dotnet/2002/04/01/asp.html

 

[Dave M.]

Thanks for the reply. Could you briefly describe how you went about
adding .pdf to the URL. Are you doing this in the response object?