Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115845
MIME-Version: 1.0
References: <CADK1yXLZzoOjjNcpZ5ZtV9kSNgw4=SW9G74o26eLdAYV5cDzAQ@mail.gmail.com>
 <CAEZPtU5STkockXmwYBQi0kd+rBtNkb9Z4UwvxMe7ozRSDTm8Ew@mail.gmail.com>
 <CAOWwgpmEpzPURtcASMH_VLNdtb0Qmhg5HEOuRFRZ4x+97KteLw@mail.gmail.com>
 <CADyq6sLBpywgXdFqGYFuKek4FHzOZpvARZa3mS_ovoDmBxbOWw@mail.gmail.com>
 <CAOWwgpnZ=vtwqD8zGDSKFNpC0Gs1VScayVXQ3GyM5-S2DmPu5g@mail.gmail.com>
 <B096EE9F-35EC-42A1-8196-F25415A373D1@php.net> <CAEZPtU4H0cXv9H9QyBCymHdc_46B93UfiHzHOAd-oOY4fZGGcw@mail.gmail.com>
In-Reply-To: <CAEZPtU4H0cXv9H9QyBCymHdc_46B93UfiHzHOAd-oOY4fZGGcw@mail.gmail.com>
Date: Wed, 25 Aug 2021 21:48:01 -0700
Message-ID: <CA+syWAPZiiNuLZnbs-u=v6jJcuNDaGm15No63KA=zbABNqnoQw@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Derick Rethans <derick@php.net>, PHP internals <internals@lists.php.net>, 
	Nicolas Grekas <nicolas.grekas+php@gmail.com>, Marco Pivetta <ocramius@gmail.com>, 
	Deleu <deleugyn@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000096f3605ca6f1308"
Subject: Re: [PHP-DEV] Guidelines for RFC post feature-freeze
From: guest271314@gmail.com (guest271314)

--000000000000096f3605ca6f1308
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi.

I read the requirements to ask for a feature. I have been following your
list. Interesting. I just want to do this
https://web.dev/fetch-upload-streaming/,
https://glitch.com/edit/#!/fetch-request-stream.

This works as expected with a Blob or File:

<?php
  $input =3D fopen('php://input', 'rb');
  $file =3D fopen('test.txt', 'a');
  stream_copy_to_stream($input, $file);
  $copy =3D fopen('test.txt', 'rb');
  echo stream_get_contents($copy);
  fclose($input);
  fclose($file);
  fclose($copy);
?>

fetch('index.php', {
  headers: { 'Content-Type': 'text/plain' },
  allowHTTP1ForStreamingUpload: true,
  method: 'post',
  body: new ReadableStream({
    start(c) {
      c.enqueue(new Blob([123]));
      c.close();
    },
  }),
})
.then((r) =3D> r.text())
.then(console.log)
.catch(console.error);

At HTML document:

POST http://localhost:8000/index.php net::ERR_FAILED
TypeError: Failed to fetch

PHP built-in server:

Invalid request (Unexpected EOF)


in PHP. I tried to unsubscribe from your list, got mail error. If you find
the time, can you kindly direct me to where this is possible in PHP, or if
you find the use case a positive addition to PHP, perhaps work towards
implementing it. Kindly unsubscribe me from your mailing list. You folks
are involved. Carry on.

On Wed, Aug 25, 2021 at 8:19 PM Pierre Joye <pierre.php@gmail.com> wrote:

> Hi,
>
> On Thu, Aug 26, 2021, 1:09 AM Derick Rethans <derick@php.net> wrote:
>
> > On 25 August 2021 18:34:18 BST, Nicolas Grekas <
> > nicolas.grekas+php@gmail.com> wrote:
> > >Le mer. 25 ao=C3=BBt 2021 =C3=A0 19:32, Marco Pivetta <ocramius@gmail.=
com> a
> =C3=A9crit
> > :
> > ,
> > >
> > >> On Wed, Aug 25, 2021 at 7:30 PM Nicolas Grekas <
> > >> nicolas.grekas+php@gmail.com> wrote:
> > >>
> > >>> I would welcome a new RFC to clarify what is allowed during the
> feature
> > >>> freeze.
> > >>>
> > >>
> > >> See https://en.wikipedia.org/wiki/Freeze_(software_engineering)
> > >>
> > >
> > >
> > >Can you please let me know how that helps?
> >
> > Maybe you didn't read the post, but generally a feature freeze in
> software
> > development is some time were no new features are added so a code base
> can
> > stabilise. This usually happens just before a release. These periods ar=
e
> > really important as they allow for 3rd party tools, documentation, etc =
to
> > be ready when a piece of software is released. On top of that, this
> period
> > can also be used by users to make sure everything is stable, and that
> there
> > are no critical bugs.
> >
>
>
> I suppose everyone knows what a freeze is.
>
> Also the issue here is not about the PHP features freeze period (RMs do a
> good job here to announce and update it well on advance).
>
> It is about amending RFC for completeness (or whatever other reasons). I
> can understand a RFC author does not want it for some random extension
> being added. However I do see challenges when it comes to the very PHP co=
re
> syntax and languages.
>
> As we expected many years ago when we introduced the RFC process, I do se=
e
> a need to slightly clarify how the core of the PHP language is handled. N=
ot
> to block any changez but really to make it clear, what we can accept, vet=
o
> possible (it is now), etc.
>
> For the discussion about whether the null intersection was a feature or a
> refinement, I would suggest just to ignore it. too late too little.
>
> best,
> Pierre
>
> >
>

--000000000000096f3605ca6f1308--