Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94627
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.15.15 as permitted sender)
To: Nikita Popov <nikita.ppv@gmail.com>,
 Nazar Mokrynskyi <nazar@mokrynskyi.com>
References: <9d7bf704-44f9-1888-0761-8a91adfa8391@mokrynskyi.com>
 <CAF+90c99WfdH+sm5piEDC=7eaKHpS7v8=WjT8Vswz2fsx5=eog@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>,
 Christoph Michael Becker <cmb@php.net>
Message-ID: <437a97a6-dd17-5631-d7e8-577e8a7fc393@gmx.de>
Date: Fri, 22 Jul 2016 12:57:28 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CAF+90c99WfdH+sm5piEDC=7eaKHpS7v8=WjT8Vswz2fsx5=eog@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Add support for arbitrary HTTP methods
From: cmbecker69@gmx.de (Christoph Becker)

On 22.07.2016 at 12:28, Nikita Popov wrote:

> On Fri, Jul 22, 2016 at 2:28 AM, Nazar Mokrynskyi <nazar@mokrynskyi.com>
> wrote:
> 
>> I want to bring here question about supporting custom http methods in
>> built-in webserver with router script.
>>
>> The problem is that GET, POST are standard methods and they work fine,
>> but for custom methods like XYZ_METHOD_ALSO_ALLOWED webserver responds
>> with 501 Not Implemented.
>>
>> 501 ideally should never happen when router script is used, since it is
>> up to router to decide whether it can handle the request or not.
>>
>> Initial bug report for additional info and references:
>> https://bugs.php.net/bug.php?id=72619
>> Sample repository to reproduce an issue:
>> https://github.com/nazar-pc/php-bug-72619
>>
>> Christoph Michael Becker said on bug tracker that this kind of change
>> will probably require an RFC, however for me this appears to be pretty
>> minor change that can barely be a breaking change to someone and it
>> should even be backported to 7.0/5.6 when/if implemented in 7.1.
>>
>> I do not code in C/C++, but I can prepare some PHPT tests for this
>> feature if someone is willing to help here.
> 
> Agree, I don't see why this would need an RFC.
> 
> I don't see a point in the HTTP request method detection -- in the end,
> applications will only be able to handle a small fraction of the request
> methods we consider "allowed". so it's not like these checks are in any way
> meaningful -- the application layer still has to deal with this itself if
> it's actually interested in generating accurate 405 responses. It's a PITA
> to keep this list updated (we're pretty bad at this -- we're very out of
> sync with the upstream implementation) and prevents use of custom methods.

After re-reading the RFC which introduced the built-in web server[1]
(which doesn't even mention HTTP methods), and finding that
non-supported methods can't even be properly handled in the router
script, I agree that we should change the web server to accept arbitrary
methods; if required, a router script can still reject methods that are
unsupported by the app.

If this would need an RFC?  Still not sure, but maybe starting with a PR
and awaiting feedback is sensible.

[1] <https://wiki.php.net/rfc/builtinwebserver>

-- 
Christoph M. Becker