1523213 - FF still tries to render PDF from 403 response instead of showing response error

Status: UNCONFIRMED

(Core :: DOM: Navigation, defect, P3)

Description

[13hu]

Attachment: pdf viewer loading PDF 403 response

To reproduce:
Request a PDF URL that gives a 403 response

• https://dl.humble.com/ops/pdfs/wavesandforms_preview.pdf

Expected:
Response handled, response content or response error page shown to user.

Actual:
FF still tries to render PDF, which doesn't work because content is either none or non-PDF.

Comment 1

[13hu]

Attachment: HAR of PDF 403 response

Comment 2

[Honza Bambas (:mayhemer)]

Why Net:HTTP? This seems to be issue with the PDF viewer or how content sniffing is setup..

Comment 3

[Honza Bambas (:mayhemer)]

The weird thing I can see is "mimeType": "application/pdf" in the HAR. This means a sniffer or a guess from the extension.

Comment 4

[Matthias Versen [:Matti]]

Isn't the unknown content decoder lining in networking ?
I moved the bug based on that assumption.

The response is without content-type header (violation of http 1.1 rfc) according to https://websniffer.cc/?url=https://dl.humble.com/ops/pdfs/wavesandforms_preview.pdf and there is no content in the response (Content-Length:0 ) which let me believe that the unknown content decoder seem to use the pdf extension for the detection.

The detection fails here and not the consumer (pdf.js) but I'm not sure why the unknown content decoder is called on a 403.

Comment 5

[Matthias Versen [:Matti]]

I do not know C++ but this looks like the place where it tries to guess based on the request URL
https://searchfox.org/mozilla-central/source/netwerk/streamconv/converters/nsUnknownDecoder.cpp#482

Comment 6

[Honza Bambas (:mayhemer)]

I think we end up here, yes:
https://searchfox.org/mozilla-central/rev/5c8ea961d04767db723a0a15e3a8f7fbca154129/uriloader/exthandler/nsExternalHelperAppService.cpp#2577

Anyway, this is for a more broad discussion. We want to render/handle 403 (and number of other error pages, like 401/7, 500, 301[2] etc) and show the content. And when c-t is missing we want to sniff.

So I kinda tend to resolve this as INVALID as all the indices show the response is a PDF. I still think this should be handled in the PDF viewer and gracefully fallback to some "this PDF is broken" message. I don't think we can handle this on the Necko level well to satisfy all possible scenarios.

Adding Dragana for thoughts.

Comment 7

[Honza Bambas (:mayhemer)]

Actually, I don't see this as a networking bug.

Dragana, please see comment 6.

Comment 8

[Dragana Damjanovic [:dragana]]

pdf viewer do have an info that the pdf cannot be rendered.

This is a broader discussion about error pages. We render network errors but not 403, 401...
I will move this to docshell because rendering will be there.

In case we decide to render such error pages we should disable sniffing by the extension for error codes.