Trying to view PDF attachment causes download

[mattfbacon]

I believe that this is because the HTTP response is missing the Content-Disposition header.

[mjl-]

Could you check the content-type (and other content-* headers) in the attachment (in the message) and in the HTTP response? Perhaps it isn't set to application/pdf, but to something like application/octet-stream? If that's the case, we could perhaps override the content-type from the attachment (though not sure if that's wise, it may be introducing security vulnerabilities). Which browser does this happen in? I regularly view PDFs in webmail in firefox, and haven't had issues yet.

[mattfbacon]

It's in firefox. The Content-Type is correctly set to application/pdf. I think it's just missing the Content-Disposition to make it inline content instead of an attachment.

[mattfbacon]

Also, if you change it from iframe to embed it works. I'll make a PR for that.

[mjl-]

I have a feeling changing the iframe to an embed can open up new problems. It seems a document in an embed has more access to the parent document. With JS possible in PDF, I wouldn't be surprised if this could result in PDFs changing the webmail document. For a discussion on differences between iframe, embed, object at https://stackoverflow.com/questions/16660559/difference-between-iframe-embed-and-object-elements

I think it's still good to understand why these downloads are happening for you. I cannot reproduce this behaviour with any browser I tried (firefox, chromium, safari, edge).

Could you try the following diff and see if that fixes this for you? It follows your initial suggestion about a missing content-disposition header. Webmail currently only adds a content-disposition header for the download endpoint. You could test the diff locally with "mox localserve". It would also be interesting to see if enabling/disabling some plugins make a difference. And are you also seeing this in another browser on the same machine?

diff --git a/webmail/webmail.go b/webmail/webmail.go
index c00b4ef..21fb591 100644
--- a/webmail/webmail.go
+++ b/webmail/webmail.go
@@ -888,6 +888,8 @@ func handle(apiHandler http.Handler, w http.ResponseWriter, r *http.Request) {
            }
            cd := mime.FormatMediaType("attachment", map[string]string{"filename": name})
            h.Set("Content-Disposition", cd)
+       } else {
+           h.Set("Content-Disposition", "inline")
        }

        _, err := io.Copy(w, ap.Reader())

[mattfbacon]

I can still reproduce in firefox, but not in chromium. Patch made no difference.

[mjl-]

And any chance of figuring out cases when it will/will not happen? Do you use the firefox builtin PDF reader or an external plugin (if that's still a thing). And does it happen with all PDF's or do some messages/PDF's not trigger the download? Which firefox version is this? And do you have plugins you could temporarily disable/enable? Does the JS debug console and/or network inspector show any logging or note that could hint at the cause of the download?

I'm still not very enthousiastic about using embed: it would require diving into the implications, which can get much in the web ecosystem.

[mjl-]

Btw, thanks for testing the diff.

[mattfbacon]

In my most recent testing none of the PDFs I tried caused a download. I still don't know what's causing it.