Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121264
Message-ID: <1a486099-eede-bb8e-5b9c-2d9b1bc6f7d1@bastelstu.be>
Date: Sat, 7 Oct 2023 17:42:06 +0200
MIME-Version: 1.0
To: Ilija Tovilo <tovilo.ilija@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <CAPyj-LD0EDYUZSOM=P9doSZRJ8LipSKKUSBHxV-bRbCV1QsYtQ@mail.gmail.com>
 <6fccfe47-21ac-fa5b-e52e-28064f26125b@bastelstu.be>
 <CAPyj-LCBnc5hfcGPGNLrabvg8mg0Z1UdmDez25NTiOExAVOsFw@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAPyj-LCBnc5hfcGPGNLrabvg8mg0Z1UdmDez25NTiOExAVOsFw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC][Under discussion] RFC1867 for non-POST HTTP verbs
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

Hi

On 10/7/23 14:06, Ilija Tovilo wrote:
> file. The most common action after a file uploads is arguably to move
> it to a permanent location using move_uploaded_file(). With a stream

I'm not sure if this is actually the most common action, at least in 
modern applications. Generally there is some kind of processing 
pipeline. You might want to strip exif metadata from images, check the 
file contents with a virus scanner, recompress images to save disk usage 
and in the end upload it to some cloud storage service (e.g. S3).

> the obvious way to achieve the same is stream_copy_to_stream().
> However, as the stream already has a file backing (if big enough, at
> least) this copy is unnecessary. Please correct me if there's
> something I have missed.

Especially with the "upload to S3" part, folks will generally already 
work with a stream abstraction, e.g. PSR-7 together with a PSR-18 HTTP 
client.

Flysystem is probably the most widely used file system abstraction, 
being included in Laravel, and it also has a "writeStream" functionality:

https://flysystem.thephpleague.com/docs/usage/filesystem-api/

> I also would really like to avoid subtle differences between the
> automatically and manually invoked files. Given that the overwhelming

Yes, that's fair. However there's already some inconsistency, because to 
my understanding you would need to check for the HTTP method to 
determine if calling the function is safe or not, no? As an application 
developer, it would be great if I could safely call this new function 
also for POST requests.

Best regards
Tim Düsterhus