Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:121947 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 95946 invoked from network); 7 Dec 2023 17:04:51 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 7 Dec 2023 17:04:51 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 37B8318005B for ; Thu, 7 Dec 2023 09:05:04 -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, HTML_MESSAGE,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-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) (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 ; Thu, 7 Dec 2023 09:05:00 -0800 (PST) Received: by mail-lf1-f53.google.com with SMTP id 2adb3069b0e04-50bf4f97752so1200992e87.1 for ; Thu, 07 Dec 2023 09:04:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701968686; x=1702573486; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qt3hT7xVgRfxBDaruqcIADyH/VkcbQ4d2zTQwpT2XRM=; b=RpijzRdN4IECDHoydFuoa3l23eetZcNEhBSfar5I/CYnFUO0q/SnR/FTTm/7qH5jdO 1TjVpS7E5tq72Cj8xqDARYD1TSqAR+MJM7pMY3bPt4kpne/m/6UKhKlW9lQXZociFHsq YwwjiTHl9ZXnBuTnxUwL6x+6sxTPXTgypl1xefeVn32q3voMUhMzVaHHWlKj4L8cDUOW iA35wdbAYQxmn+NSRaLs6LPcmAXG4J3wbBNEEOrQnUZ0lfYs0wtf0dtdBWwKd5AsEuNt 3QhbY0A5PDSc3mDH9kT8TOaFbp0CFVwYpitdwmz95CsnkbESljuzzXRXEAWA4I35+fFl 7RNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701968686; x=1702573486; h=cc: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=qt3hT7xVgRfxBDaruqcIADyH/VkcbQ4d2zTQwpT2XRM=; b=NYKilyB/IXBQ4U0iuQw1IsYlwbwNm2HUN6pE+jiM7zgpWpO3epAUByFb6p3UQn/ka5 1nHnuqr+GlIxuVw9FmCZ9oGzMiwbLTyRT0D5MbnZGxFw3C7df+bP/G5WMCntJfFnAVmR fSrAesH+KXzGdAv53QHbe9NFogRLJm7G7FuSXC8pWThU+w11IzbrV0einR5+qBHXnuVU q9XDp3HtT7Wxni63mO5fS0ivNFSZc+LMokfkgjPSSGQ5sajwHFfZOLAvBobzpG43UR8J aREukdiF7HlAozTXJY+rHcD8zKGhei1BPpgKqMd/24tKlzu3qvSyXEF5JnX0naD3L0+4 UBxw== X-Gm-Message-State: AOJu0YzJOxEeDumPhYUjEx1ghGNY+eVaTTgcy1z7dK83tPxX37jdodeP JVnNPz2P3tQlVZjP/HfZrNEAFRa5f2UWH4mo4ZE= X-Google-Smtp-Source: AGHT+IE8dRtZ+quB+2sKOaF3yJG/KJjviA/HR0TLoPARiQ1BtveIlWFdhR1lw+nODvY2nUGsWr2N2ov8FfkCED5oHlE= X-Received: by 2002:a05:6512:6c9:b0:50b:f836:9027 with SMTP id u9-20020a05651206c900b0050bf8369027mr2415653lff.93.1701968685428; Thu, 07 Dec 2023 09:04:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 7 Dec 2023 11:04:33 -0600 Message-ID: To: Ilija Tovilo Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000e9f4e4060bee76d3" Subject: Re: [PHP-DEV] Re: [RFC][Under discussion] RFC1867 for non-POST HTTP verbs From: aweptimum@gmail.com (Sam I) --000000000000e9f4e4060bee76d3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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) On Tue, Dec 5, 2023 at 2:29=E2=80=AFPM Ilija Tovilo wrote: > Hi everyone > > On Fri, Oct 6, 2023 at 3:44=E2=80=AFPM Ilija Tovilo > wrote: > > > > I'd like to announce an RFC that proposes adding a new function called > > parse_post_data() to expose the existing functionality to userland, so > > that the mechanism can be used for other HTTP verbs. > > > > https://wiki.php.net/rfc/rfc1867-non-post > > I took a closer look at RoadRunner regarding file uploads and noticed > that $input_stream will not be useful to it after all. RoadRunner > handles files directly in its Go server by parsing the multipart body, > storing any files to disk, and only transferring the file handles > (along with any post data) to the PHP workers. New SAPIs could instead > tweak sapi_module.read_post() when handling a new request. We can add > these parameters if somebody can present a valid use-case, for now I > opted to remove the $input_stream and $content_type parameters. > > Please let me know if you have any more feedback. I will wait at least > 2 weeks before going forward with a vote, as this is a bigger change > to the RFC. > > Ilija > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > --000000000000e9f4e4060bee76d3--