Create a BodyParser to parse MultipartFormData directly to a stream

[BillyAutrey]

Play Version

2.7

API

Scala (Ideally, both)

Feature Description

As of now, the documentation only details how to use parse.multipartFormData and parse.temporaryFile. Both approaches store temporary files, which is not ideal in a Dockerized deployment. The alternative that is suggested is to create your own BodyParser to handle the bytes as they stream in.

I propose that a multipartFormData parser should be created, which provides the body as an Akka Stream (of type Source[ByteString, Any]. This will allow you to skip storing temporary files, and gives you an idiomatic and recommended way to handle the bytes by passing it to the next destination. This is especially helpful for use cases where you are using Play as a simple frontend or gateway, and just want to pass the bytes anyway.

Providing a streamed approach encourages developers to evaluate streaming as a solution for handling files. Right now, the recommendation to build your own BodyParser deters new developers from considering anything outside of temporary file storage.

[octonato]

Hi @BillyAutrey,

Thanks for the suggestion. I added this issue to the backlog, but it can take sometime before someone can find time to pick it. Would you be interested in sending a PR?

We can guide you throught it if needed.

[BillyAutrey]

Hey @renatocaval,

Sure! I can give it a shot.

[smadarasmi]

@BillyAutrey Was there any progress on this? I would like to tackle this.

@renatocaval This would be my first contribution to Play. I've went over the Contribution guide.

We can guide you throught it if needed.

What would be the best way to go about this? Should I provide some details in this issue about the approach I would take, or should we communicate elsewhere?

[octonato]

@smadarasmi, thanks for willing to take a stab on it.

The best approach is to send a pull request. It doesn't need to be a finished/perfect one. Just start with it and we iterate on the PR giving suggestions and polishing it until it gets ready for merge.

You can also drop here your thoughts about how you want to implement, but a PR is a better because the code is always the best form to explain something. ;-)