Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94626
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <9d7bf704-44f9-1888-0761-8a91adfa8391@mokrynskyi.com>
References: <9d7bf704-44f9-1888-0761-8a91adfa8391@mokrynskyi.com>
Date: Fri, 22 Jul 2016 12:28:03 +0200
Message-ID: <CAF+90c99WfdH+sm5piEDC=7eaKHpS7v8=WjT8Vswz2fsx5=eog@mail.gmail.com>
To: Nazar Mokrynskyi <nazar@mokrynskyi.com>
Cc: PHP internals <internals@lists.php.net>, Christoph Michael Becker <cmb@php.net>
Content-Type: multipart/alternative; boundary=94eb2c05b3aac8179a053836e3c1
Subject: Re: [PHP-DEV] Add support for arbitrary HTTP methods
From: nikita.ppv@gmail.com (Nikita Popov)

--94eb2c05b3aac8179a053836e3c1
Content-Type: text/plain; charset=UTF-8

On Fri, Jul 22, 2016 at 2:28 AM, Nazar Mokrynskyi <nazar@mokrynskyi.com>
wrote:

> Hi internals,
>
> 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.

Nikita

--94eb2c05b3aac8179a053836e3c1--