Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124281 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id AEF881A009C for ; Mon, 8 Jul 2024 08:45:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1720428435; bh=1TyW1fhiBr6hInDI8AwjKN/5h0OyqIyRqdS0sdXbYE8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=kNFz3qZOIUsTJB7VgOgSeZiU1LafP8aNnbKJCUjaLo1ITcFtJ1HNiQTMD7MkSTj// 1OtwTWelI2Q+pCz12WY/cb7F5m/I/F16lnhqaCQGXSHgjAVn9E7OCbqS+iWXDt27AD 4us1an45ew/B34woS8ldXzKRXnODGmCjO32tmhLCvdn9pWpFQYet12tDEhpmDgUctk tq6flxkEZsZ22DMcE2sLbE5C6p0Ck2xeKJq4IZRKj/dlPZLo4WEuiesfKJuFEhJzqm F1KPQ4RxqslPQIDJfMZolqCxmIJsbBU7Ie9ZEGkRU5FJTKTBwQSOpjs15HS2/XJacl +RvMzHdI2xLUQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 2679C18069B for ; Mon, 8 Jul 2024 08:47:15 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,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,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (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 ; Mon, 8 Jul 2024 08:47:14 +0000 (UTC) Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-42662d80139so8049525e9.0 for ; Mon, 08 Jul 2024 01:45:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720428349; x=1721033149; 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=7/Z5SHcatpYuhKZHACRMbAgodH8peKsgTQgrE6LrmUQ=; b=eYJHIvqIGnhjFrZvOXHeHPjoDlm8+2d/uV2IFn+mUSD6tqX8EcxKlDoawpePyxopqG BzW+hh5mKSkyHP4P9MzDMtVDQ3Ay/RetxCxXOvhQrLYItA2sKAboV1/i7AHQZKNg32Qq PsTd+E3lYRyyUwuEgYY7Tq9WCFQHYYlZXarRyyz6TfrMmvgEFhlLoJb/kjECThYhOE0i XeqRxTEoMM0MWrgtusJVBbYxW6iNuekA4krAzglB53LDFQ7dR7VEecRltvx6pySyBvAw KkNT/Ubqmv68ZRr2a0QB3nYUEKv4tYQZ419VXCJ4RIZ3Ukxo1puJ4cR0qIzVnj1mgUvL +QSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720428349; x=1721033149; 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=7/Z5SHcatpYuhKZHACRMbAgodH8peKsgTQgrE6LrmUQ=; b=P2owZJJK88cfJXkOb6/mEprBH4V12PI7+PrQFz2H7x6zqlE/sDb6ksA8REMlPjooQt pNGYASE9wc0vegJhLU5s+jDeMrIF05dI4zVFuvaoV2E7HD4RFnO4GagW+rKTGnRKQtn4 h27yiep2Q2lX4hdWpqD5D1NSDg8otsK658s7gqsvI+A+2jlMywGLOkWVoM5IU0a0LD+5 j2PcaqRVZZFDM/L+vrgiu1e6iDykBKPrNaMrI7wQO+IdfzJa4PfoHhiH+m4dZR1iw5mJ Lw1psFUZrDy8vCtVzY22pR4fCzJd/jxDv7lrMuAUvz+nOmnHu+fwaZqduxWARxNKDe3l j2YQ== X-Gm-Message-State: AOJu0YxQX6bJO24w84AON2RPOsBC+hlnv/gKYwLIuyRXNErf1oyo2Df1 dY5Gce8IlaRTaJ+W9FZBN8EBDTNJNdRnt4/yjwyVsUUy+o6gmYOUuDTG2bP62aGS5E3oL01nwIe EII+CW2PYQz2L+czt8BpGh57691dQcfM= X-Google-Smtp-Source: AGHT+IFsJ/4W31xCPYuPtWYfKJV2HWek8n4KduoBJcbXUqG+Y2HNj1KudK9AgJMpjD8CGPUc0QieYO7SI9bUFapo8qM= X-Received: by 2002:a05:600c:4ca8:b0:426:51d1:63c3 with SMTP id 5b1f17b1804b1-42651d16511mr57659995e9.38.1720428348553; Mon, 08 Jul 2024 01:45:48 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 8 Jul 2024 11:45:37 +0300 Message-ID: Subject: Re: [PHP-DEV] [RFC][Vote] RFC1867 for non-POST HTTP verbs To: Ilija Tovilo Cc: PHP internals Content-Type: multipart/alternative; boundary="00000000000093c0c5061cb870e9" From: udaltsov.valentin@gmail.com (Valentin Udaltsov) --00000000000093c0c5061cb870e9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 24 Jan 2024=E2=80=AF=D0=B3. at 14:01, Ilija Tovilo wrote: > Hi Sara > > Thank you for your feedback. > > On Tue, Jan 23, 2024 at 8:41=E2=80=AFPM Sara Golemon wr= ote: > > > > On Mon, Jan 22, 2024 at 1:24=E2=80=AFAM Ilija Tovilo > wrote: > > > > > I started the vote on the "RFC1867 for non-POST HTTP verbs" RFC. > > > https://wiki.php.net/rfc/rfc1867-non-post > > > > > > > 1/ This function reaches into the SAPI to pull out the "special" body > > data. That's great, but what about uses where providing an input strin= g > > makes sense. For that, and for point 2, I'd suggest > > `http_parse_query(string $query, ?array $options =3D null): array|objec= t`. > > The RFC previously included support for the $input_stream variable > (string is not very appropriate for multipart because the input may be > arbitrarily large). The implementation wasn't complex, but it required > duplication of all the reads to support both a direct read from the > SAPI and a read from the stream, duplication of some limit checks and > special passing of the streams to avoid SAPI API breakage. > > As for actual use cases, I found limited evidence that this function > would be useful for worker-based services _right now_. Most services > handle request parsing in some other layer. For example, RoadRunner > has a Go server that stores the file to disk, and then just passes the > appropriate path to PHP in the $_FILES array. It seems to me that a > custom input would be useful exclusively for a web server written in > PHP. The one that was pointed out to me (AdapterMan) handles requests > as strings, which would not scale for multipart requests. > > I don't mind getting back to this if AdapterMan rewrites request > handling to use streams. Adding back the $input_stream parameter can > be done with no BC breaks. But for the time being, I don't think the > motivation is big enough to justify the added complexity. > > Additionally, because multipart is used exclusively as a request > content type, it isn't useful in a general sense either, because a PHP > request will typically only receive one request (but potentially > multiple responses, in case it communicates with other servers). > > > 2/ `request_` represents a new psuedo-namespace, functions are easier t= o > > find and associate if we keep them grouped. I recommend 'http_` becaus= e > it > > compliments the very related function `http_build_query()`, and for the > > version of this function which refers directly to the request: > > `http_parse_request(?array $options =3D null) : array|object`. > > That's fair. If the name bothers you I can create an amendment RFC. I > think http_parse_body() would be a bit more appropriate, because > request implies more than just the body. > > Ilija > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > Hi, Ilija! I think that removing $input_stream should be revisited. The problem with Go/RoadRunner/PHP is that PHP parses `a[]=3D1&a[]=3D2&a[]= =3D3` differently from other languages. PHP: [a =3D> [1,2,3]] GO: map[a[]:[1 2 3]] See https://github.com/roadrunner-server/roadrunner/issues/1696 and https://github.com/roadrunner-server/roadrunner/issues/1963#issuecomment-22= 09403600 for more details. To mitigate this issue, RoadRunner allows raw body on the PHP side by setting `http.raw_body =3D true`. Here's where request_parse_body would = be useful if it accepts other streams. -- Best regards, Valentin --00000000000093c0c5061cb870e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, 24 Jan 2024=E2=80=AF=D0=B3. at 14:01, Ilija T= ovilo <tovilo.ilija@gmail.com<= /a>> wrote:
Hi Sara

Thank you for your feedback.

On Tue, Jan 23, 2024 at 8:41=E2=80=AFPM Sara Golemon <pollita@php.net> wrote:
>
> On Mon, Jan 22, 2024 at 1:24=E2=80=AFAM Ilija Tovilo <tovilo.ilija@gmail.com&g= t; wrote:
>
> > I started the vote on the "RFC1867 for non-POST HTTP verbs&q= uot; RFC.
> > https://wiki.php.net/rfc/rfc1867-non-post
> >
>
> 1/ This function reaches into the SAPI to pull out the "special&q= uot; body
> data.=C2=A0 That's great, but what about uses where providing an i= nput string
> makes sense.=C2=A0 For that, and for point 2, I'd suggest
> `http_parse_query(string $query, ?array $options =3D null): array|obje= ct`.

The RFC previously included support for the $input_stream variable
(string is not very appropriate for multipart because the input may be
arbitrarily large). The implementation wasn't complex, but it required<= br> duplication of all the reads to support both a direct read from the
SAPI and a read from the stream, duplication of some limit checks and
special passing of the streams to avoid SAPI API breakage.

As for actual use cases, I found limited evidence that this function
would be useful for worker-based services _right now_. Most services
handle request parsing in some other layer. For example, RoadRunner
has a Go server that stores the file to disk, and then just passes the
appropriate path to PHP in the $_FILES array. It seems to me that a
custom input would be useful exclusively for a web server written in
PHP. The one that was pointed out to me (AdapterMan) handles requests
as strings, which would not scale for multipart requests.

I don't mind getting back to this if AdapterMan rewrites request
handling to use streams. Adding back the $input_stream parameter can
be done with no BC breaks. But for the time being, I don't think the motivation is big enough to justify the added complexity.

Additionally, because multipart is used exclusively as a request
content type, it isn't useful in a general sense either, because a PHP<= br> request will typically only receive one request (but potentially
multiple responses, in case it communicates with other servers).

> 2/ `request_` represents a new psuedo-namespace, functions are easier = to
> find and associate if we keep them grouped.=C2=A0 I recommend 'htt= p_` because it
> compliments the very related function `http_build_query()`, and for th= e
> version of this function which refers directly to the request:
> `http_parse_request(?array $options =3D null) : array|object`.

That's fair. If the name bothers you I can create an amendment RFC. I think http_parse_body() would be a bit more appropriate, because
request implies more than just the body.

Ilija

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php


Hi, Ilija!

I think that removing $input_= stream should be revisited.
The problem with Go/RoadRunner/PHP is that P= HP parses `a[]=3D1&a[]=3D2&a[]=3D3` differently from other=C2=A0lan= guages.

PHP: [a =3D> [1,2,3]]
GO:=C2= =A0map[a[]:[1 2 3]]


Best regards,
Valentin
--00000000000093c0c5061cb870e9--