Valery Piashchynski
Valery Piashchynski
👋 Hey. Please, update to the latest version. We support only the latest minor releases.
Got u, thanks for the report. I'm unsure where this happens (PHP side or RR side), because RR doesn't limit the `application/x-www-form-urlencoded` to the only POST method... Anyway, I'll have...
@ekisu According to the existing HTTP RFC-7231, the `DELETE` (https://httpwg.org/specs/rfc7231.html#DELETE) method has no defined behavior on parsing body (which you sent with `application/x-www-form-urlencoded` header). > A payload within a DELETE...
@ekisu It's actually not replaced, but not parsed at all 😃. Unfortunately, this is not possible to send the entire body with the `application/x-www-form-urlencoded`, and method which has no defined...
I'm not a PHP dev, so, sorry, I cannot refer to the `PHP-FPM`. > application/x-www-form-urlencoded request bodies if they're not HEAD or OPTION You're right, but this is old behavior,...
> Would it be possible to treat it as a contentStream instead? Not sure if this would abide to the standards, but it would mimic the "send it as a...
Hey @ekisu 👋🏻 We discussed this FR with our PHP team, and as promised, I'm here with the results. Since this is not a standard, we put this ticket in...
@ekisu Hey 👋🏻 After some discussion in the nearby ticket, we decided to send the untouched post form values data to the worker even if this is the `DELETE` method....
Remember that that is valid only for the `x-www-form-urlencoded` values. Not for the `multipart` form values. The release is scheduled for Thursday, 25 Aug.
> Would it be possible to implement non-blocking solution? Send multiple queries and wait for response afterwards. Or this is more like proxy? Yep, this is a very famous optimization...