Re: RFC1867 (multipart/form-data) PUT requests

From: Date: Wed, 28 Jun 2023 06:18:37 +0000
Subject: Re: RFC1867 (multipart/form-data) PUT requests
References: 1 2 3 4 5 6 7 8  Groups: php.internals 
Request: Send a blank email to internals+get-120707@lists.php.net to get a copy of this message
Hi Andreas, śr., 28 cze 2023 o 07:55 Andreas Heigl <andreas@heigl.org> napisał(a): > ... > While I like not adding more Superglobals, it seems like we are adding > more and more functions to retrieve the different parts of a > Request-Object... > > So when we are at it: Why don't we introduce exactly that? A > Request-Object that has all the methods. And which is immutable. > > And one method request(): \Request > I agree with the above, this would allow us to clean up the global namespace in the future. My personal use cases for PHP are mostly queue workers/event stream consumers, so the usual request/response model SAPI is used rarely. But I understand that it's not the most used case. Adding a couple of additional functions to a set of already ones just adds more symbols not always used. Ideally, I'd see an HTTP module in the future enabled in request/response-oriented SAPI but that's a different story. > > I deliberately didn't call it getRequest (or > get_request) to not > confuse people why there isn't also a post_request or > put_request or > ... you get the picture) > > One additional function in global namespace and then we can use one of > the request-objects that are already out in the wild. I don't think > there's a need to invent the wheel again. > > The advantage might be that no matter how many calls to > request() you > will always get the same result. The Request as it came in. > That sounds like a use for a const?! Just my .50€ Cheers, Michał Marcin Brzuchalski

« previous php.internals (#120707) next »