Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom hook to handle mime type interpretation #1829

Closed
JeanJPNM opened this issue Jul 5, 2021 · 3 comments
Closed

Custom hook to handle mime type interpretation #1829

JeanJPNM opened this issue Jul 5, 2021 · 3 comments

Comments

@JeanJPNM
Copy link
Contributor

JeanJPNM commented Jul 5, 2021

Is your feature request related to a problem? Please describe.
Possible solution for #1438, better thought of and more maintainable than #1687.

Describe the solution you'd like
A custom hook that lets the user determine how the body of a request/response should be parsed based on its mime type.
The hook receives the mime type or the request/response headers as input and returns a value from an enum, telling the framework how to interpret the body.

Describe alternatives you've considered

  • Two fields in the svelte.config.js file (one for buffer and other for text) that contain a list of regexes that are tested against a mime type to determine how the body should be parsed.
  • Hardcoded list of mime types for body parsing.

How important is this feature to you?
For me is a very important feature since it will enable users to send binary content from endpoints, and let them define specific handling for some mime types such as image/svg+xml.

Additional context
This feature requires svelte kit to make hooks accessible to adapters.
This feature was made considering that #1563 may become a part of the framework hence the use of an enum instead of a boolean.
This feature is also intended to replace #1687.

@JeanJPNM
Copy link
Contributor Author

JeanJPNM commented Jul 5, 2021

Here is a quick and working implementation, will be converted to a draft or pull request if this issue is considered relevant

@benmccann
Copy link
Member

@JeanJPNM do you think we still need this after #1890 and #1900?

@JeanJPNM
Copy link
Contributor Author

JeanJPNM commented Jul 13, 2021

No I don't think this is necessary anymore, since the the body will default to an instance of Uint8Array instead of a string it is pretty easy to parse it inside an endpoint.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants