Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:121962 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 73309 invoked from network); 8 Dec 2023 13:00:37 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 8 Dec 2023 13:00:37 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id C96A9180031 for ; Fri, 8 Dec 2023 05:00:49 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-qv1-f45.google.com (mail-qv1-f45.google.com [209.85.219.45]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 8 Dec 2023 05:00:49 -0800 (PST) Received: by mail-qv1-f45.google.com with SMTP id 6a1803df08f44-67adea83ea6so12855756d6.0 for ; Fri, 08 Dec 2023 05:00:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702040435; x=1702645235; darn=lists.php.net; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=mFvI/CYu7yUbbpYJDRtaQMQIF15j8dVMa+nAceB0OvY=; b=UKzTEfOIMzpXFojf+M2sdzVU7SHiSLqftSHwld3nyvFXaqJev7+ibeifadqvwkMoIs gOwJUAdbux3m6l/GmvxwSaPaFg1Cs7Xv+c/BlI+t9VdHa5Mo+K1ahpjmNvgJAL7a0/Zp JzN50MWtM3tbDRICV2TTEe67m3JiXo5bU+wPxnZgCUHlmhjDQZGOfoBE/xAUbV6zg7W9 fRgFeN8xEcsj9/JRZqZsVPBBEeaNrKzSe7DZ0Kf7V97QJWH6/OZptvGOvuJ2Nvb5fCm+ vBIT9ljUfawo4OZAGRny7QsHUBMENx9fHhTipf+rqOPrI+lGgsVScN5OGZcRvX5/9zig jF6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702040435; x=1702645235; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mFvI/CYu7yUbbpYJDRtaQMQIF15j8dVMa+nAceB0OvY=; b=T/g3ZPV3eZA7BAZOvAGJ57l1SJwOpd0Bt4Auxix+UGeMXWzVBmGh1Otj6k8eaYzfF9 AdDtzzuvoRUcXQz28m60zWeoRRQ1qBBnxRCoj2rW+VhqiZ277u/Keczyntn0k5XDL/Bo pLlQPW8J3l5ijPApOEU+wLVT0Ydem/hyCqvF1KIxb3agp54W5pD8CrSMLEC04jCdPTCM RhvkAYTXlnIrzni60ymKz4LEdDTTD+h+H1LSzRKdQlAHCcGYPLZRvOHoTkW0KuwwwvWL YvYLuQBfkjLvRSs9d30GsGayWJFwEEgKWF8sSUewgJNfFvUKZFebIlRjnwqn16eYLs77 4rKw== X-Gm-Message-State: AOJu0Yx+VzEzIn+ChLGoZt2YzUlci4eCjCbWHwrUOgIn4rS2v6HJq67w AV8UDMG/EU8OVMfFf/JZFnqD9bxr64Z4f5GeJqlznKgOZRATT8WQ X-Google-Smtp-Source: AGHT+IHKPEPXmsPuVpyA+FG4oFMAD0IYtU+RLOn7BR4zb/+GibFAv3tXp1VjlpVjHmjZ2yJ/muGZvTgGyCAHqLjNnUU= X-Received: by 2002:a05:6214:4c11:b0:67a:a721:b1b6 with SMTP id qh17-20020a0562144c1100b0067aa721b1b6mr3952957qvb.113.1702040434483; Fri, 08 Dec 2023 05:00:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 8 Dec 2023 14:00:23 +0100 Message-ID: To: PHP internals Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Re: [RFC][Under discussion] RFC1867 for non-POST HTTP verbs From: tovilo.ilija@gmail.com (Ilija Tovilo) Hi Sam >> On Fri, Oct 6, 2023 at 3:44=E2=80=AFPM Ilija Tovilo wrote: >> > https://wiki.php.net/rfc/rfc1867-non-post On Thu, Dec 7, 2023 at 6:04=E2=80=AFPM Sam I wrote: > > Hey, I'm not sure if this is bikeshedding, but the concept of parsing bod= ies for non-POST requests lands really close to a proposal for adding a QUE= RY method to the HTTP standard. > Draft: https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-safe-meth= od-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 / Ela= stic 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