Allow changing the content-type of attachents #2132

Closed
opened 2026-02-05 03:02:35 +03:00 by OVERLORD · 3 comments
Owner

Originally created by @dorianim on GitHub (Feb 28, 2021).

Describe the feature you'd like
It would be nice to be able to change the content-type header that is supplied when downloading attachments.
Currently, this is always set to application/octet-stream which causes issues in some scenarios.

Describe the benefits this feature would bring to BookStack users
When downloading files on mobile devices (e.g. Android or IOS) the content-type is used to determine which app to open a file in. If it is set to application/octet-stream the device is unable to detect the actual type of file and therefore cannot open it in the correct app.
I noticed this when trying to distribute an OpenVPN profile using BookStack. On a phone I can download the file but is just won't allow opening it in the OpenVPN Connect app. When the content type header is set to application/x-openvpn-profile though, it works perfectly fine.

Would be nice for this to be added, as it is a fundamental requirement for use cases like this :)

Originally created by @dorianim on GitHub (Feb 28, 2021). **Describe the feature you'd like** It would be nice to be able to change the content-type header that is supplied when downloading attachments. Currently, this is always set to `application/octet-stream` which causes issues in some scenarios. **Describe the benefits this feature would bring to BookStack users** When downloading files on mobile devices (e.g. Android or IOS) the content-type is used to determine which app to open a file in. If it is set to `application/octet-stream` the device is unable to detect the actual type of file and therefore cannot open it in the correct app. I noticed this when trying to distribute an OpenVPN profile using BookStack. On a phone I can download the file but is just won't allow opening it in the OpenVPN Connect app. When the content type header is set to `application/x-openvpn-profile` though, it works perfectly fine. Would be nice for this to be added, as it is a fundamental requirement for use cases like this :)
OVERLORD added the 🌔 Out of scope label 2026-02-05 03:02:35 +03:00
Author
Owner

@ssddanbrown commented on GitHub (Feb 28, 2021):

Thanks for the request @CodeCrafter912.

I wouldn't really want to add an option that's this specific and this technical to be honest since it would increase maintenance burden while introducing new potential routes for user error.

There's been an ongoing discussion in #1464 to offer a non-forced download for attachments. I don't know exactly though if simple stopping the forced response type would achieve what you want. Do you know if a plainly served config file works correctly?

I've tested you case with an openvpn profile on my Android phone and my iPad. Although it would require a couple of steps (Download then select file, or on iPad open the file then share to OpenVPN) in both cases I was able to download an the profile from a BookStack attachment and import the profile.

@ssddanbrown commented on GitHub (Feb 28, 2021): Thanks for the request @CodeCrafter912. I wouldn't really want to add an option that's this specific and this technical to be honest since it would increase maintenance burden while introducing new potential routes for user error. There's been an ongoing discussion in #1464 to offer a non-forced download for attachments. I don't know exactly though if simple stopping the forced response type would achieve what you want. Do you know if a plainly served config file works correctly? I've tested you case with an openvpn profile on my Android phone and my iPad. Although it would require a couple of steps (Download then select file, or on iPad open the file then share to OpenVPN) in both cases I was able to download an the profile from a BookStack attachment and import the profile.
Author
Owner

@dorianim commented on GitHub (Feb 28, 2021):

Hi @ssddanbrown thanks for your reply.
It is true, that it works by downloading it and then importing it manually. In some cases this gets kind of complicated, though. Firefox on Android for example changes the file ending to .bin and in some scenarios the file can be hard to find as it is downloaded to Android/data/com.android.chrome/Downlodas. It just makes things needlessly complicated. I have verified that it works just as I want using this snippet:

      header('Content-type: application/x-openvpn-profile');
      header("Content-Disposition: attachment; filename=\"Profile.ovpn\"");
      http_response_code(200);
      readfile($filePath);

Using this, OpenVPN Connect is opened immediately. I have now worked around the problem by specifying a link to this script in the attachment.
I understand that it opens room for user error to make the content-type completely open. Maybe it would be possible to determine it using the mime database of the system?

@dorianim commented on GitHub (Feb 28, 2021): Hi @ssddanbrown thanks for your reply. It is true, that it works by downloading it and then importing it manually. In some cases this gets kind of complicated, though. Firefox on Android for example changes the file ending to .bin and in some scenarios the file can be hard to find as it is downloaded to `Android/data/com.android.chrome/Downlodas`. It just makes things needlessly complicated. I have verified that it works just as I want using this snippet: ``` header('Content-type: application/x-openvpn-profile'); header("Content-Disposition: attachment; filename=\"Profile.ovpn\""); http_response_code(200); readfile($filePath); ``` Using this, OpenVPN Connect is opened immediately. I have now worked around the problem by specifying a link to this script in the attachment. I understand that it opens room for user error to make the content-type completely open. Maybe it would be possible to determine it using the mime database of the system?
Author
Owner

@ssddanbrown commented on GitHub (Nov 22, 2021):

Coming back to this, there's little user desire for setting custom attachment content-types, while being something that would require further UI and maintenance from the project, so it's not really a feature I think would be worth building in so I'm going to close this off.

We have since added support for non-forced-download served attachments, by clicking the attachment while holding down Ctrl or by adding ?open=true to the attachment link. These will serve with a non-forced-mime although the mime-type is ran through an allow-list for security reasons. I'd be happy to accept a PR that adds this to our mime allow-list, but I'd need proof that the mimes of such files are detected correctly (And ideally I'd want an example file to test the PR myself).

Otherwise, we do have the logical theme system which can be used to hook into middleware events and set headers where desired; So you might be able to use this to set specific headers if such attachment requests can be detected.

@ssddanbrown commented on GitHub (Nov 22, 2021): Coming back to this, there's little user desire for setting custom attachment content-types, while being something that would require further UI and maintenance from the project, so it's not really a feature I think would be worth building in so I'm going to close this off. We have since added support for non-forced-download served attachments, by clicking the attachment while holding down `Ctrl` or by adding `?open=true` to the attachment link. These will serve with a non-forced-mime although the mime-type is ran through an allow-list for security reasons. I'd be happy to accept a PR that adds this to our mime allow-list, but I'd need proof that the mimes of such files are detected correctly (And ideally I'd want an example file to test the PR myself). Otherwise, we do have the [logical theme system](https://github.com/BookStackApp/BookStack/blob/master/dev/docs/logical-theme-system.md) which can be used to hook into middleware events and set headers where desired; So you might be able to use this to set specific headers if such attachment requests can be detected.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/BookStack#2132