Attachment content type not correct #178

New Issue

OVERLORD · 2026-02-04T17:41:41+03:00

OVERLORD commented

2026-02-04 17:41:41 +03:00

Originally created by @zotanmew on GitHub (Apr 26, 2022).

On v1.1.0, when clicking on an attachment it isn't served with the proper content type, causing the raw contents of the file to be displayed as text.

Originally created by @zotanmew on GitHub (Apr 26, 2022). On v1.1.0, when clicking on an attachment it isn't served with the proper content type, causing the raw contents of the file to be displayed as text. <img width="1680" alt="image" src="https://user-images.githubusercontent.com/18512463/165385080-c45a1da0-a9fe-4868-96ea-49d742cecfd2.png">

OVERLORD added the bug label 2026-02-04 17:41:41 +03:00

OVERLORD closed this issue

2026-02-04 17:41:53 +03:00

OVERLORD commented

2026-02-04 17:41:59 +03:00

@dbrennand commented on GitHub (Apr 27, 2022):

I can't seem to reproduce this 😞

Steps

Select Card > Attachment > From Computer > Choose a .png
Image uploads successfully. Navigate to /attachments/<:id>/download/<:name> endpoint in browser and Content-Type and Content-Disposition headers are set properly.
```
content-disposition: inline
content-type: image/png
```

Was this an attachment uploaded prior to v1.1.0?

Is the Content-Disposition header set to attachment; <attachment name>?

@dbrennand commented on GitHub (Apr 27, 2022): I can't seem to reproduce this 😞 # Steps 1. Select Card > Attachment > From Computer > Choose a .png 2. Image uploads successfully. Navigate to `/attachments/<:id>/download/<:name>` endpoint in browser and `Content-Type` and `Content-Disposition` headers are set properly. ``` content-disposition: inline content-type: image/png ``` Was this an attachment uploaded prior to `v1.1.0`? Is the `Content-Disposition` header set to `attachment; <attachment name>`?

OVERLORD commented

2026-02-04 17:42:11 +03:00

@zotanmew commented on GitHub (Apr 28, 2022):

Yes, the attachment was uploaded on v1.0.0, not v1.1.0.

Content-Disposition is set to inline.

Here is the header output behind the reverse proxy. Same result.

@zotanmew commented on GitHub (Apr 28, 2022): Yes, the attachment was uploaded on `v1.0.0`, not `v1.1.0`. `Content-Disposition` is set to `inline`. Here is the header output behind the reverse proxy. Same result. ![image](https://user-images.githubusercontent.com/18512463/165651765-7a9a15dd-3de2-4d86-9d4b-c5e3279423ec.png)

OVERLORD commented

2026-02-04 17:42:12 +03:00

@zotanmew commented on GitHub (Apr 28, 2022):

I also just tested uploading an attachment on v1.1.1, same thing happens I'm afraid

@zotanmew commented on GitHub (Apr 28, 2022): I also just tested uploading an attachment on `v1.1.1`, same thing happens I'm afraid

OVERLORD commented

2026-02-04 17:42:15 +03:00

@meltyshev commented on GitHub (Apr 28, 2022):

Maybe I should also specify filename with inline Content-Disposition 🤔 I'm trying to do something with this, but I can't reproduce to check it... Could you try to change the line 61 in server/api/controllers/attachments/download.js from contentDisposition = 'inline'; to contentDisposition = `inline; ${inputs.filename}`;?

@meltyshev commented on GitHub (Apr 28, 2022): Maybe I should also specify filename with inline Content-Disposition 🤔 I'm trying to do something with this, but I can't reproduce to check it... Could you try to change the line 61 in `server/api/controllers/attachments/download.js` from `contentDisposition = 'inline';` to ``contentDisposition = `inline; ${inputs.filename}`;``?

OVERLORD commented

2026-02-04 17:42:22 +03:00

@dbrennand commented on GitHub (Apr 28, 2022):

I'll try to look into this a little more this evening 🤞🏻

It's interesting that @zotanmew has reproduced this on localhost (I'm assuming the docker-compose setup) and on an instance at todo.ztn.sh.

Out of interest @zotanmew, you mention that you have a reverse proxy in front of Planka, what one are you using? It may be helpful so I can try to reproduce a similar setup. Also, do you use the same reverse proxy when you see this issue at todo.ztn.sh and when you tested with localhost?

Interestingly in the screenshot, I can't see the Content-Type response header. Whereas, in my response I had content-type: image/png.

@dbrennand commented on GitHub (Apr 28, 2022): I'll try to look into this a little more this evening 🤞🏻 It's interesting that @zotanmew has reproduced this on `localhost` (I'm assuming the docker-compose setup) and on an instance at `todo.ztn.sh`. Out of interest @zotanmew, you mention that you have a reverse proxy in front of Planka, what one are you using? It may be helpful so I can try to reproduce a similar setup. Also, do you use the same reverse proxy when you see this issue at `todo.ztn.sh` and when you tested with `localhost`? Interestingly in the screenshot, I can't see the `Content-Type` response header. Whereas, in my response I had `content-type: image/png`.

OVERLORD commented

2026-02-04 17:42:27 +03:00

@zotanmew commented on GitHub (Apr 28, 2022):

@dbrennand I'm using nginx with the bog standard reverse proxy setup. Though I have my doubts this is related due to being able to reproduce it on the docker host directly. Yeah, no content-type headers received, neither through nginx, nor directly. Very interesting

@zotanmew commented on GitHub (Apr 28, 2022): @dbrennand I'm using nginx with the bog standard reverse proxy setup. Though I have my doubts this is related due to being able to reproduce it on the docker host directly. Yeah, no content-type headers received, neither through nginx, nor directly. Very interesting

OVERLORD commented

2026-02-04 17:42:29 +03:00

@dbrennand commented on GitHub (Apr 28, 2022):

@dbrennand I'm using nginx with the bog standard reverse proxy setup. Though I have my doubts this is related due to being able to reproduce it on the docker host directly. Yeah, no content-type headers received, neither through nginx, nor directly. Very interesting

Hi @zotanmew

Thanks for that extra info 🙂

I'll see if I can also reproduce this issue without a reverse proxy in between and report back. Using a PNG image.

@dbrennand commented on GitHub (Apr 28, 2022): > @dbrennand I'm using nginx with the bog standard reverse proxy setup. Though I have my doubts this is related due to being able to reproduce it on the docker host directly. Yeah, no content-type headers received, neither through nginx, nor directly. Very interesting Hi @zotanmew Thanks for that extra info 🙂 I'll see if I can also reproduce this issue without a reverse proxy in between and report back. Using a PNG image.

OVERLORD commented

2026-02-04 17:42:30 +03:00

@dbrennand commented on GitHub (Apr 28, 2022):

Spun up the stack from docker-compose.yml using the latest version from DockerHub. No reverse proxy used.

I get a similar response where the Content-Type is missing:

Output using xh

➜  planka git:(master) ✗ xh :3000/attachments/704421698463597579/download/Screenshot%202022-04-28%20175953.png \
    Cookie:accessToken=x -v --all
GET /attachments/704421698463597579/download/Screenshot%202022-04-28%20175953.png HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Cookie: accessToken=x
Host: localhost:3000
User-Agent: xh/0.15.0

HTTP/1.1 200 OK
Connection: keep-alive
Content-Disposition: inline
Date: Thu, 28 Apr 2022 17:14:25 GMT
Keep-Alive: timeout=5
Transfer-Encoding: chunked
X-Exit: success
X-Powered-By: Sails <sailsjs.com>

+-----------------------------------------+
| NOTE: binary data not shown in terminal |
+-----------------------------------------+

But, I also get the same in the browser (the Content-Type header is missing) but, it still shows the image correctly:

So I can't reproduce 🤷🏻 😞

Maybe your PNG image is corrupted somehow or something?

@dbrennand commented on GitHub (Apr 28, 2022): Spun up the stack from `docker-compose.yml` using the latest version from DockerHub. No reverse proxy used. I get a similar response where the `Content-Type` is missing: Output using `xh` ``` ➜ planka git:(master) ✗ xh :3000/attachments/704421698463597579/download/Screenshot%202022-04-28%20175953.png \ Cookie:accessToken=x -v --all GET /attachments/704421698463597579/download/Screenshot%202022-04-28%20175953.png HTTP/1.1 Accept: */* Accept-Encoding: gzip, deflate, br Connection: keep-alive Cookie: accessToken=x Host: localhost:3000 User-Agent: xh/0.15.0 HTTP/1.1 200 OK Connection: keep-alive Content-Disposition: inline Date: Thu, 28 Apr 2022 17:14:25 GMT Keep-Alive: timeout=5 Transfer-Encoding: chunked X-Exit: success X-Powered-By: Sails <sailsjs.com> +-----------------------------------------+ | NOTE: binary data not shown in terminal | +-----------------------------------------+ ``` But, I also get the same in the browser (the `Content-Type` header is missing) but, it still shows the image correctly: ![Screenshot 2022-04-28 184717](https://user-images.githubusercontent.com/52419383/165815621-84f72767-7cf9-4c86-832e-0a23befbb4f1.png) ![Screenshot 2022-04-28 184723](https://user-images.githubusercontent.com/52419383/165815650-8c3188a9-4163-4035-826c-1f690b63a8e6.png) So I can't reproduce 🤷🏻 😞 Maybe your PNG image is corrupted somehow or something?

OVERLORD commented

2026-02-04 17:42:43 +03:00

@meltyshev commented on GitHub (Apr 28, 2022):

I will add Content-Type for inline attachments such as images or pdf. I also want to add some other headers. So this will be fixed soon.

@meltyshev commented on GitHub (Apr 28, 2022): I will add Content-Type for inline attachments such as images or pdf. I also want to add some other headers. So this will be fixed soon.

OVERLORD commented

2026-02-04 17:42:48 +03:00

@zotanmew commented on GitHub (Apr 30, 2022):

I can confirm that this fixed the issue. Thank you!

@zotanmew commented on GitHub (Apr 30, 2022): I can confirm that this fixed the issue. Thank you!

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/planka#178