1

I have some Angular code that makes an API call to retrieve a PDF for users. When the request is made, there are no errors thrown on the front end or from the network. The network responds with the PDF except it's all in bytecode.

This once worked in Chrome and as far as I know the code hasn't changed in a good while, so I'm not sure what has happened. It's even weirder that it works fine for me locally but on my server I'm just getting the long bytecode string in the response. Any ideas? With it working correctly locally it's tough for me to troubleshoot, but I wanted to see if anyone else has had this issue (perhaps recently?)

Service:

  getPDF(): Observable<HttpResponse<Blob>> {
    let url = `${environment}/v9/Folder/${this.folderId}/view`;
    return this.http.get(url, { observe: 'response', responseType: 'blob' });
  }

Component:

  viewFolderCertificate = () => {
    this.viewService.getPDF()
      .subscribe(response => {
        saveAs(response.body, 'view.pdf');
      });
  }

This works perfectly for IE11, Edge, and Firefox. I've looked around to see if there's been any updates to Chrome that may be causing this--no luck yet. I'm not running any kind of Adblocker and other people have experienced the issue on my server so I don't think it's anything to do with my own machine.

It appears as though the headers are set properly for PDFs in the back end .net code:

        response.Content.Headers.ContentType = new MediaTypeHeaderValue("application/pdf");
        response.Content.Headers.ContentLength = stream.Length;
        response.Content.Headers.ContentDisposition = new ContentDispositionHeaderValue("inline")
Timbo773
  • 163
  • 1
  • 12

1 Answers1

1

You probably are not setting the content type header in the response. Please look at Proper MIME media type for PDF files and set the header.

If this does not work, check if you have following headers: X-ContentType-Options: nosniff (so the browser does not try to guess the content type) and Content-Disposition: attachment; filename="your.pdf" (so the content is always downloaded as a file with the name specified).

Marek Puchalski
  • 3,286
  • 2
  • 26
  • 35
  • Hey thanks for the response, this was a good idea as I hadn't looked into this yet. It seems like the headers are being set properly in the back end code, I've updated my post with the lines. – Timbo773 Jun 29 '20 at 20:02
  • 1
    Can you see the header appear when you go into the web tools in Chrome? If this does not work, then the next issue would be that your Adobe/Foxit/Whatever you are using is not correctly integrated with your system. Does it appear only on your computer but also someone elses? – Marek Puchalski Jun 29 '20 at 20:06
  • Yep, in dev tools headers it comes back at `Content-Type: application/pdf`. It works for me locally and others locally... just on the server it doesn't work. The PDF was set up to be downloaded rather than viewed, or at least that's how it worked in the past (and how it works in all other browsers). – Timbo773 Jun 29 '20 at 20:09
  • 1
    BTW. Seems there are some other ways that can cause issues: https://silicophilic.com/chrome-pdf-viewer-not-working/ – Marek Puchalski Jun 29 '20 at 20:10
  • 1
    Two more headers you might want to consider: `X-ContentType-Options: nosniff` and `Content-Disposition: attachment; filename="your.pdf"` (or other appropriate filename for the content type). – Marek Puchalski Jun 29 '20 at 20:16
  • 1
    I appreciate the responses, I've tried a number of things out you suggested with no luck before realizing this issue is only occurring in Chrome 83... all past versions it works. I'm taking a look at the release notes to see what has changed. – Timbo773 Jun 29 '20 at 21:06