Hi Sam >> On Fri, Oct 6, 2023 at 3:44 PM Ilija Tovilo <tovilo.il...@gmail.com> wrote: >> > https://wiki.php.net/rfc/rfc1867-non-post On Thu, Dec 7, 2023 at 6:04 PM Sam I <awepti...@gmail.com> wrote: > > Hey, I'm not sure if this is bikeshedding, but the concept of parsing bodies > for non-POST requests lands really close to a proposal for adding a QUERY > method to the HTTP standard. > Draft: > https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-safe-method-w-body > Discussion: > https://github.com/httpwg/http-extensions/labels/safe-method-w-body > > It's meant to address the recent need for complex querying (GraphQL / Elastic > Search) that necessitates using POST but loses the default caching of GET. > I think this RFC could serve as the groundwork for supporting QUERY if it's > extended to other MIME types in the future as Larry suggested. But QUERY > probably still has years to go before there is a consensus on it (I think > it's been talked about for 6+ years now)
Looking at the RFC, it doesn't seem like multipart is an intended format for QUERY requests. application/x-www-form-urlencoded is intended and should work as-is with request_parse_body(). Parsing anything other than multipart and form-data is possible, but not at all related to QUERY (and IMO not desirable). You can implement a QUERY endpoint in PHP today (if your web server supports it) by reading from php://input. It's worth noting that PHPs built-in server does not support custom HTTP methods and will return a 501. I don't think there's anything actionable here. Please clarify if I'm missing something. Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
