Probelm with Edge and ContentType="application/pdf" And content-disposition "inline;filename=report.pdf"

Fixed Issue #7045462


Mar 29, 2016
This issue is public.
Reported by 23 people

Sign in to watch or report this issue.

Steps to reproduce


Repro Steps:

Expected Results:

To open a new tab with the pdf file like all other browsers

Actual Results:

Dev Channel specific:


Posted by Aaronasdegsdg on 8/13/2015 at 3:33 PM

WARNING: This is a complete hack and runs the risk of breaking if/when Microsoft ever fixes this issue.

As I mentioned in my comment, earlier, you’ll see that Edge issues two requests whenever you view a PDF. To me, it looks like the browser is sending the initial request and then the PDF viewer is issuing its own request when it is opened. If you look at the headers in that second request, you’ll see an odd DLNA header coming down, which should just be for media streaming, but that leads me to my workaround…

  1. When the request is received in your handler or page, check if the user agent string contains “Edge/12.” If it doesn’t, send your PDF back normally. If it does, move on to step #2.
  2. Check if the HTTP Header “GetContentFeatures.DLNA.ORG” exists. If it doesn’t, that means that the request came from the browser. Just send back a Content-Type header of “application/pdf” and an empty body. If the header exists, then the request came from the PDF viewer and you can send your PDF back normally.

Basically, the handler treats that first request as a HEAD request and then responds with the full PDF if we determine that the request is coming from the PDF viewer. The risk we run here is if Microsoft removes that DLNA header later on, Edge will not render the PDF properly.

Posted by Eugene Friend on 3/21/2016 at 3:36 PM

This issue seems to be similar to this issue:

Still no solution but maybe this might increase the priority of the fix?

We’ve been struggling with this for a while, finally narrowed it down to the odd duplicate request behavior.

Posted by sphanley on 8/11/2015 at 8:06 AM

I want to confirm that in my workplace, we’re experiencing essentially the exact same thing that Aaronasdegsdg has described in his comment. In our application, we have the exact same sort of setup where we’re returning a PDF from a temporary database then deleting it, but edge, unlike other browsers where this works normally, is sending a duplicate request for the URL and therefore is erroring when the second request doesn’t have anything left to respond with.

Posted by Aaronasdegsdg on 8/3/2015 at 1:13 PM

I’m seeing a similar issue and it looks like it’s due to Edge making dual requests for any inline PDF. To test, you can run Fiddler or the Edge developer tools and navigate to any PDF on the web. You’ll notice that the browser is making two requests to the server. That second request can cause issues with dynamically-generated PDFs depending on how the PDF is generated.

In my case, I have a handler that returns a byte array from a temp database and immediately deletes it so we aren’t keeping a huge pdf byte array around any longer than we have to. When the second request comes though, my handler issues an exception because it can’t locate the byte array and the browser throws up the “Something’s keeping this PDF from opening.” error.


0 attachments

    Comments and activity

    • Microsoft Edge Team

      Changed Assigned To to “Mara P.”

      Changed Assigned To to “Venkat K.”

      Changed Assigned To from “Venkat K.” to “Saranya K.”

      Changed Assigned To to “Amit K.”

      Changed Assigned To from “Amit K.” to “Anoop P.”

      Changed Assigned To from “Anoop P.” to “IE S.”

      Changed Status to “Fixed”

    • Why is this marked as external and will this ever be fixed?

    • I am also facing same issue. Can you please update, what does status External mean and will it be ever fixed?

    • I am also facing same issue. Can you please update, what does status External mean and will it be ever fixed?

    • Hello,

      Thank you for providing this information about the issue. We are pleased to report this feature is fixed in Edge 15063 and is available in our latest Insider Preview build.

      Best Wishes,
      The MS Edge Team

    • BUG is still present in Edge 15063. Still making duplicate requests. The browser itself sends the first request then the viewer triggers a second request. Big FAIL Microsoft!

    • Edge 15063 doesn’t resolve this bug, Could you please fix it ASAP? It is causing many problems.

    • Confirm this is still occurring for PDF content, under Edge/15.15063 In our case, we have a big complicated server-side process that produces a rather enormous PDF file. The server-side script is being hit twice, and this means that instead of it taking over 20 seconds (just about bearable), it takes twice that time to download and render in Edge - plus of course, the doubled server load from running two parallel queries.

    • I can also confirm it is still happening in Edge/15.15063.

      When my application generates reports it feeds them back as dynamic PDFs (using local RDLC files) and sets the content-disposition to inline; filename="some-report-name.pdf".

      Not only does Edge make two requests for every PDf report, causing double the processing on my server, but it seems to ignore the filename provided in the content-disposition as well. So if the user attempts to save the PDF, they are prompted with a file name of untiltled.pdf. (Very annoying.)

    • I like Edge, but I stopped using it from the day I discovered this major error, reported it, and never found an answer. With every new Edge version, I test it with our application, and see the same error, and keep putting Edge aside. I don’t know how difficult this bug is, but this is not ok.

    • I even tried the work around which is documented at It still didn’t work. This is really frustrating since lots of our pdfs are encrypted and rendered back to clients with inline mode.

    • This has caused endless hassle and costs, it really needs fixing. Have to consider whether to encourage clients to move to Chrome - just to get a reasonable interface to PDF documents. This, on top of the issues IE 11 has with PDF in iframes (not handling zindex correctly) has been a dire strain on development resources. Currently client is mid-way between w7 and w10 … so IE11 and Edge are both in use. No further fixes are being applied bu MS to IE11 so we are having to extract images from PDF to mimic a PDF handler. Then we find this issue with Edge … it’s pushing us over the edge!

    • With Edge 16.16299 (Windows Fall Creator Update) there were made changes here. We did the workaround described in this issue and it worked "well": But now with the new version of Edge (16.16299) it isn’t working anymore and it happen, that the PDFs are corrupted (0 bytes large). Take care if you implemented this workaround somewhere.
      What you also take care of is that Edge is doing two requests like before.

    • The workaround implementation (classic ASP) in our system is luckily still working. Tested today on free virtual machine (Win 10 x64 with Edge 16.16299). I can confirm that double request issue still persist.

    • I am also having this same issue with the "double request". This issue started after installing Fall Creators Update(1709), was fine on 1703. First request comes in correctly without the GetContentFeatures.DLNA.ORG header, second request comes in with GetContentFeatures.DLNA.ORG header. Also the second request comes in without any cookies that should be present, like the asp authorization cookie. Without that cookie that cookie the user is basically not authorized. And the session id passed on the second request is different from the first request so you can’t access any session variables on the request.

    • We also get double request for our PDF-forms.
      Even worse, the second request from the PDF-viewer has no session cookie, thus we can’t show a correct PDF at all :(

    • I have been struggled with this for two days. Solved the problem today without the hack code. We are using handler to render the pdf stream. During the debug I noticed that the ProcessRequest function is called twice, using the fiddler, I also noticed the first time, it returns 0 byte stream, and the second time it’s 0 byte too. So I make sure even when the session is null (which I am using to decide the filename), I write something out instead of just call return. Wow, what a huge difference, now my pdf is rendering beautifully.

      Just hope this can help somebody in someway.

    • Another challenge we are facing is the PDF file size. Seems like as soon it’s bigger than 500 KB, the file will have problem to render as inline mode. We ended up to create a handler inheriting from HttpTaskAsynHandler, which will write the outputstream async. Now, the inline pdf is showing correctly.

    • 2 Years and this major issue isn’t fixed… Wow way to go MS!

    You need to sign in to your Microsoft account to add a comment.

    Sign in