By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,779 Members | 1,291 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,779 IT Pros & Developers. It's quick & easy.

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

P: n/a
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
Nov 17 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
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.
-----Original Message-----
Should you be able to map a any file extension to the ASP.NET dll andhave it execute ASP.NET script, just like an .aspx page, when it isrequested by a browser. If not, why bother giving us the ability tocreate application mappings.

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

When a browser requests that .aspx page, if I try to return that PDFresult as a response back to the calling browser, the browser does notrecognize it as a PDF (thus loading up Adobe Acrobat, etc.). This iseven after I have set the content type to "application/pdf".
The browser is smart enough to know that this isn't a typical HTMLpage, 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, whichI understand, but I do not want to happen. I'd rather it at least tryto save it as a PDF. If I click Open, then it quite naturally triesto open it as an .aspx page, which means it opens up the PDF resultsin Visual Studio, which is also not what I want.

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

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

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

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

Nov 17 '05 #2

P: n/a
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...04/01/asp.html

On 16 Jul 2003 15:23:45 -0700, David <dm*******@yahoo.com> wrote:
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


--
Craig Deelsnyder
Microsoft MVP - ASP/ASP.NET
Nov 17 '05 #3

P: n/a


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?

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 17 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.