Edge PDF Viewer Second Request with new ASP.Net Session

Confirmed Issue #16358526 • Assigned to Gourab K.

Details

Author
Patrick H.
Created
Mar 13, 2018
Privacy
This issue is public.
Found in
  • Microsoft Edge
Found in build #
41.16299
Reports
Reported by 10 people

Sign in to watch or report this issue.

Steps to reproduce

As has been documented several times, the PDF viewer in Edge incorrectly invokes a second HTTP GET request when opening a PDF document in Edge. See:

https://stackoverflow.com/questions/31850624/microsoft-edge-pdf-inline-issue-same-issue-again

https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/7045462/

In these write ups, the authors have focused on the issue of the second request, which while annoying, wasteful and slow is not the real problem. The real issue is that the second request is done without passing the ASP.NET SessionId cookie. This makes serving dynamically rendered PDFs using ASP.NET session variables impossible. Ultimately, this is the cause of much suffering and why so many users claim PDFs do not work using Edge. PDFs work fine in Edge, but PDFs that are dynamically rendred by the server using data or authentication tokens stored in session variables do not.

To highlight the issue, I have created the following website:

http://beta.fultonhomes.com/edgepdftest/logon.aspx

  1. Browse this link using Chrome or IE.
  2. On the initial page, enter a username and hit submit.
  3. Note that the username (which is stored in a session variable) is displayed on the subsequent page. Also note the ASP.Net Session ID.
  4. Click the “View PDF” link.
  5. A PDF will be rendered and displayed in a new window/tab. Note that the username is correctly displayed in the PDF, and the ASP.Net Session ID matches the session ID listed on the previous page (it’s the same session).

Then . .

  1. Browse to the above link using Edge.
  2. On the initial page, enter a username and hit submit.
  3. Note the session variable username and ASP.Net Session ID is displayed.
  4. Click the “View PDF” link.
  5. Note that in the rendered PDF the username is BLANK and the ASP.Net Session ID DOES NOT match the Session ID listed on the previous page!
  6. Realize Microsoft really screwed the pooch on this.
  7. Get a fix for this into production.

For even more fun, you can use Wireshark to see that when the “View PDF” link is clicked, Edge (unlike other browsers) makes two HTTP GET requests. The first request contains the ASP.NET_SessionId cookie of the current session. The second HTTP GET request does not. Hence, the ASP.NET session information is not available to the server on the second request and the PDF is not rendered correctly (the username session variable is empty).

Attachments

0 attachments

    Comments and activity

    • Microsoft Edge Team

      Changed Assigned To to “Manoj B.”

    • Any clue where that second ASP.Net Session ID came from?

    • I’m seeing the same behavior, but cannot determine where the second asp.net session id is coming from. And the behavior of Edge changes depending on the response to the second request. If our handler returns an empty response body to the second (bad session) request, Edge will hang and never display the PDF. But if our handler returns an error message in the second request, the PDF (from the first request) will display.

    • Out of control software MicrosoftPdfReader.exe launched by edge is abysmal. Obviously no QA done.

    • Joshua and Seth,

      The second ASP.Net session ID is issued by the server. This is fundamental to how ASP.NET works. All consumers (browsers) of ASP.Net webpages are assigned a unique Session ID cookie. Like all cookies, the Session ID is stored by the browser and included in subsequent requests. It does this until the cookie expires, which in the case of Session ID only persists for the current browser session. On the server side, developers can access a “Session” object and store data associated with each browser session. This data is never exposed to the client browser, so it is a great place to store things like user credentials or login status.

      If a client browser makes a request without a Session ID cookie, the server considers this to be a new session and assigns a new unique Session ID cookie.

      Thus, the problem really isn’t the second ASP.Net Session ID, but the fact that the Edge PDF viewer makes its second HTTP request without including the original ASP.Net Session ID. Essentially, it’s as if the Edge PDF viewer opens its own unique session with the web server, rather than use the current browser session. This breaks websites, like ours, which check to see if a user is logged in before rendering and delivering PDF content.

    • Microsoft Edge Team

      Changed Assigned To from “Manoj B.” to “Gourab K.”

      Changed Status to “Confirmed”

    • I can also confirm on Microsoft Edge 42.17134.1.0, with server-side generated HTML having an embeded

      the invocation of “linkto.pdf” also arrives on the server twice, with a session cookie distinct than the one of the main HTML page (and the PDF requests are not shown in the F12 Network debugging session).
      PS: Sorry, if this post does not help, please remove it.

    • Ooops! Something removed the HTML snippet above. (Please remove the post above, as I cannot do that):
      Server-side HTML having an embedded

      
          
      
      

      the invocation of “linkto.pdf” also arrives on the server twice, with a session cookie distinct than the one of the main HTML page (and the PDF requests are not shown in the F12 Network debugging session).
      PS: Sorry, if this post does not help, please remove it.

    • The same problem occurs with JSESSIONID cookies which are the session cookie for Apache Tomcat. First a HEAD request comes through that correctly contains the session cookie which is followed by a GET request that doesn’t contain the session cookie.

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

    Sign in