mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-05-04 18:08:46 +03:00
Allow changing the content-type of attachents #2132
Closed
opened 2026-02-05 03:02:35 +03:00 by OVERLORD
·
3 comments
No Branch/Tag Specified
development
l10n_development
release
v26-03
ci_fixing
codeberg-actions
lexical_may_2026
MilnerMart/development
sort_rule_text
GamerClassN7/impersonations-for-admin
Zhey-on/feature/csp-image-css-controls-6033
tortillas5/development
clauvaldez/mfaReset
llm_only
vectors
McTom234/oidc-key-algorithms
docker_env
drawio_rendering
user_permissions
ldap_host_failover
svg_image
prosemirror
captcha_example
fix/video-export
v26.03.4
v26.03.3
v26.03.2
v26.03.1
v26.03
v25.12.9
v25.12.8
v25.12.7
v25.12.6
v25.12.5
v25.12.4
v25.12.3
v25.12.2
v25.12.1
v25.12
v25.11.6
v25.11.5
v25.11.4
v24.11.4
v25.11.3
v25.11.2
v25.11.1
v25.11
v25.07.3
v25.07.2
v25.07.1
v25.07
v25.05.2
v25.05.1
v25.05
v25.02.5
v25.02.4
v25.02.3
v25.02.2
v25.02.1
v25.02
v24.12.1
v24.12
v24.10.3
v24.10.2
v24.10.1
v24.10
v24.05.4
v24.05.3
v24.05.2
v24.05.1
v24.05
v24.02.3
v24.02.2
v24.02.1
v24.02
v23.12.3
v23.12.2
v23.12.1
v23.12
v23.10.4
v23.10.3
v23.10.2
v23.10.1
v23.10
v23.08.3
v23.08.2
v23.08.1
v23.08
v23.06.2
v23.06.1
v23.06
v23.05.2
v23.05.1
v23.05
v23.02.3
v23.02.2
v23.02.1
v23.02
v23.01.1
v23.01
v22.11.1
v22.11
v22.10.2
v22.10.1
v22.10
v22.09.1
v22.09
v22.07.3
v22.07.2
v22.07.1
v22.07
v22.06.2
v22.06.1
v22.06
v22.04.2
v22.04.1
v22.04
v22.03.1
v22.03
v22.02.3
v22.02.2
v22.02.1
v22.02
v21.12.5
v21.12.4
v21.12.3
v21.12.2
v21.12.1
v21.12
v21.11.3
v21.11.2
v21.11.1
v21.11
v21.10.3
v21.10.2
v21.10.1
v21.10
v21.08.6
v21.08.5
v21.08.4
v21.08.3
v21.08.2
v21.08.1
v21.08
v21.05.4
v21.05.3
v21.05.2
v21.05.1
v21.05
v21.04.6
v21.04.5
v21.04.4
v21.04.3
v21.04.2
v21.04.1
v21.04
v0.31.8
v0.31.7
v0.31.6
v0.31.5
v0.31.4
v0.31.3
v0.31.2
v0.31.1
v0.31.0
v0.30.7
v0.30.6
v0.30.5
v0.30.4
v0.30.3
v0.30.2
v0.30.1
v0.30.0
v0.29.3
v0.29.2
v0.29.1
v0.29.0
v0.28.3
v0.28.2
v0.28.1
v0.28.0
v0.27.5
v0.27.4
v0.27.3
v0.27.2
v0.27.1
v0.27
v0.26.4
v0.26.3
v0.26.2
v0.26.1
v0.26.0
v0.25.5
v0.25.4
v0.25.3
v0.25.2
v0.25.1
v0.25.0
v0.24.3
v0.24.2
v0.24.1
v0.24.0
v0.23.2
v0.23.1
v0.23.0
v0.22.0
v0.21.0
v0.20.3
v0.20.2
v0.20.1
v0.20.0
v0.19.0
v0.18.5
v0.18.4
v0.18.3
v0.18.2
v0.18.1
v0.18.0
v0.17.4
v0.17.3
v0.17.2
v0.17.1
v0.17.0
v0.16.3
v0.16.2
v0.16.1
v0.16.0
v0.15.3
v0.15.2
v0.15.1
v0.15.0
v0.14.3
v0.14.2
v0.14.1
v0.14.0
v0.13.1
v0.13.0
v0.12.2
v0.12.1
v0.12.0
v0.11.2
v0.11.1
v0.11.0
v0.10.0
v0.9.3
v0.9.2
v0.9.1
v0.9.0
v0.8.2
v0.8.1
v0.8.0
v0.7.6
v0.7.5
v0.7.4
v0.7.3
0.7.2
v.0.7.1
v0.7.0
v0.6.3
v0.6.2
v0.6.1
v0.6.0
v0.5.0
Labels
Clear labels
🎨 Design
📖 Docs Update
🐛 Bug
🐛 Bug
:cat2:🐈 Possible duplicate
💿 Database
☕ Open to discussion
💻 Front-End
🐕 Support
🚪 Authentication
🌍 Translations
🔌 API Task
🏭 Back-End
⛲ Upstream
🔨 Feature Request
🛠️ Enhancement
🛠️ Enhancement
🛠️ Enhancement
❤️ Happy feedback
🔒 Security
🔍 Pending Validation
💆 UX
📝 WYSIWYG Editor
🌔 Out of scope
🔩 API Request
:octocat: Admin/Meta
🖌️ View Customization
❓ Question
🚀 Priority
🛡️ Blocked
🚚 Export System
♿ A11y
🔧 Maintenance
> Markdown Editor
pull-request
Mirrored from GitHub Pull Request
No Label
🌔 Out of scope
Milestone
No items
No Milestone
Projects
Clear projects
No project
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/BookStack#2132
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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-streamwhich 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-streamthe 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-profilethough, it works perfectly fine.Would be nice for this to be added, as it is a fundamental requirement for use cases like this :)
@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.
@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: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?
@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
Ctrlor by adding?open=trueto 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.