Re: Re: [RFC][Under discussion] RFC1867 for non-POST HTTP verbs

Hi Sam >> On Fri, Oct 6, 2023 at 3:44 PM Ilija Tovilo <tovilo.ilija@gmail.com> wrote: >> > https://wiki.php.net/rfc/rfc1867-non-post On Thu, Dec 7, 2023 at 6:04 PM Sam I <aweptimum@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