Middleware and StreamingRequestMiddleware

[HLeithner]

While I'm trying to overcome the 64KiB limit based on the discussion at reactphp/http#412 I found out that this is not possible with the current Middleware implementation by framework-x.

Framework X bypasses the default ReactPHP HttpServer Middleware handling code by creating it's own MiddlewareHandler and only pass a closure to the HttpServer. The HttpServer tries to detect the StreamingRequestMiddleware so it's disabling it's default "Limiting Middlewares", which of course is not possible because only a closure with it's own MiddlewareHandler is provided.

Any idea how to solve this issue?

[clue]

@HLeithner Excellent question!

There's indeed a 64 KiB default limit for the request body when using the built-in web server as covered in the documentation https://framework-x.clue.engineering/docs/api/request/#uploads

You're right that this can indeed by configured on the underlying HttpServer but is not currently exposed in Framework X. Accordingly, exposing this in Framework X isn't really too hard, as we could simply pass a custom configuration value through to the underlying HttpServer.

The main reason why this wasn't done yet: The request body will always be kept in memory to avoid any disk I/O. This means that for large request bodies, we could potentially end up storing megabytes or even gigabytes in memory for incoming requests.

What do you think about this, I wonder how we could handle this?

[skydiablo]

I would prefere an mix of all of this.

1. Just add an Option so the Developer can deside how many max memory will be allocated by requests.
2. If the Max reached, the memory will dumped to Disk and the new File Stream should proxied the old stream-object.

[motzel]

I was just about to propose this myself.

[motzel]

What's more, I was thinking of introducing a soft and hard limit. Everything below the soft limit would be handled as it is now, between soft and hard limit would be dumped to disk, and above it would be skipped silently (maybe along with some attribute in the request). The soft limit could then even stay at the current 64KB level.

[clue]

I agree swapping out to the filesystem is probably the way to go, but unfortunately it's not as easy as it sounds. The current request parser expects the request body to be kept in memory when parsing, so this will require a substantial change.

On top of this, the filesystem is inherently blocking and as such rather costly which makes this particularly hard to work with in a non-blocking environment such as the built-in web server (see also #86). We could spawn child processes to handle the blocking I/O, but it's easy to see this may consume substantial resources when concurrent requests come into play.

Longer term, I'm definitely interested in bringing in this feature as suggested, but we're talking working on this full-time for several days minimum. I wonder if there's enough interest so sponsoring would be an option, in particular if there are commercial projects that show interest in this feature (https://github.com/sponsors/clue). For what it's worth, I've also already built S3 and FTP adapters for ReactPHP, so this could potentially be a starting point to avoid local disk I/O.

Short term, I wonder if we could introduce a way to increase the limit and leave if up to the user to balance memory requirements for their use case.

More input is much appreciated!

[pfk84]

This is an absolute dealbreaker for me - I need to handle quite a lot uploaded files, mainly documents but also user avatars etc. all of which are way bigger than 64KB. Even worse I found out about this limitation only after investing quite a lot time into refactoring the current project to ReactPHP and then lately using Framework X.

While being able to increase the limit just like in ReactPHP would definitely help a bit, the memory usage indeed becomes an issue very quickly. My project runs on several (auto-scaling) "Cloudlets" where the smallest instance begins with just 128 MB of RAM. The tiny footprint + impressive performance of the built-in ReactPHP webserver and the resulting tiny Docker images seemed to be a perfect fit...

Unfortunately, I don't know enough about the internals and aforementioned limitations of the request parser to propose a solution... I have a feeling that being able to pipe the request body as a stream through a handler/middleware that on detecting the start of a file fires an event where one could handle the file (again, as a stream) and e.g. write/pipe it to disk would be a nice way.

[clue]

@pfk84 Thank you for your feedback and for supporting this project as a sponsor, this definitely helps us prioritize outstanding feature requests! 🥇

I agree with everything you've said and I'm happy to hear you enjoy how well X performs in Docker containers! This also happens to be what we're working on at the moment, so that's definitely an area of high interest to us!

Once the outstanding Docker instructions and features are done, I'm happy to prioritize taking a look at file uploading again. The discussion above (#69 (reply in thread)) contains a few pointers of what the implementation could look like. Expect an update in the next couple of weeks 👍

[pfk84]

Thanks for the quick response! Also very glad to hear about the focus on Docker... :)

I will continue with my evaluation of Framework X and will most likely contact you directly if hopefully the uploads will be the only (main) issue left so we can talk about possible further support on that matter and maybe even more... Keep up the great work!

[clue]

Always happy to help if you have any questions! 👍 First batch of Docker instructions have already been merged with #136, expect more updates in the next week or two