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

File Uploads #442

Open
Blacksmoke16 opened this issue Aug 7, 2024 · 0 comments
Open

File Uploads #442

Blacksmoke16 opened this issue Aug 7, 2024 · 0 comments

Comments

@Blacksmoke16
Copy link
Member

One of the next use cases I'd like to tackle is that of uploading files. Currently there isn't a great way to handle this because using HTTP::FormData.parse from the stdlib. I think it would be nice if a lot of this was abstracted away and were able to just work with already uploaded files. The current plan is like:

  • Opt in feature, that when enabled will check the content type of each request, and if it's multipart/form-data consume the body to store normal properties in a URI::Params on the request obj, then store files in a Hash(String, ATH::UploadedFile)

    • This would likely be implemented as an event listener on the request event after routing. This'll ensure the data is available for other listeners and value resolvers and such
  • The files are saved to /tmp, and will have some logic that'll delete them when the request is finished

  • The uploaded file obj will be like name : String, type : String?, size : UInt64, temp_name : String, where temp_name is the path to the file on the server. It'll also have a #move method to move it to another location out of /tmp before the request finishes. This also gives you time to upload it to S3 or whatever

  • Would then be easy enough to do something like:

@[ARTA::Post("/upload")]
def upload_file(@[ATHA::MapUploadedFile] upload : ATH::UploadedFile) : Nil
  # ...
end

which would be a pretty nice API vs working with HTTP::FormData.parse directly.

The annotation would have the ability to define AVD::Constraint(s) on it, as well as set the name of the form data field, and what HTTP status code should be used if validation fails. This'll make things fairly easy to control the supported mime types, max size, etc.

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

No branches or pull requests

1 participant