-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Remove support for redundant request media types in the API (#5874)
Currently, every API endpoint that takes a request body supports (or at least declares to support) 4 media types: * `application/json` * `application/offset+octet-stream` * `application/x-www-form-urlencoded` * `multipart/form-data` Supporting multiple media types has a cost. We need to test that the various media types actually work, and we need to document their use (e.g., providing examples for each supported type). In practice, we mostly don't... but we still need to. In addition, the user, seeing the list of supported types, has to decide which one to use. Now, the cost could be worthwhile if the multiple type support provided value. However, for the most part, it doesn't: * `application/offset+octet-stream` only makes sense for the TUS endpoints. Moreover, for those endpoints it's the only type that makes sense. * `application/x-www-form-urlencoded` is strictly inferior to JSON. It doesn't support compound values, and it doesn't carry type information, so you can't, for example, distinguish a string from a null. It's potentially susceptible to CSRF attacks (we have protections against those, but we could accidentally disable them and not notice). Its main use is for form submissions, but we don't use HTML-based submissions. * `multipart/form-data` shares the downsides of `application/x-www-form-urlencoded`, however it does have a redeeming quality: it allows to efficiently upload binary files. Therefore, it has legitimate uses in endpoints that accept such files. Therefore, I believe it is justified to reduce the API surface area as follows: * Restrict `application/offset+octet-stream` to TUS endpoints and remove support for other types from those endpoints. * Remove `application/x-www-form-urlencoded` support entirely. * Restrict `multipart/form-data` support to endpoints dealing with file uploads. Note that I had to keep `multipart/form-data` support for `POST /api/cloudstorages` and `PATCH /api/cloudstorages/<id>`. That's because they accept a file-type parameter (`key_file`). I don't especially like this. Key files are not big, so the efficiency benefits of `multipart/form-data` don't matter. Therefore, I don't think we really need to support this type here; it would be more elegant to just use JSON and Base64-encode the key file contents. However, I don't have time to make that change right now, so I'm leaving it for another time.
- Loading branch information
Showing
5 changed files
with
33 additions
and
421 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.