Hi!
> think raphf is far more of practical use. Why should HTTP, or even more
> HTTPS or HTTP2, be any different than another service, especially when
Which "another service"?
> HTTP APIs are so common nowadays.
HTTP APIs are common, but almost none of them ever require persistent
connections. The nature of HTTP is a stateless protocol oriented for
short-lived connections (yes, I know there are exceptions, but they are
rare and mostly abuse HTTP rather than use it for intended purposes).
> With default of raphf.persistent_handle.limit=-1 (unlimited):
> █ mike@smugmug:~$ time php -r 'for ($i=0;$i<20;++$i) {(new
> http\Client("curl","google"))->enqueue(new http\Client\Request("GET",
> "http://www.google.at/";))->send();}'
I'm not sure why you need persistence here - it's all happening within
one request - or why would you make 20 connections to the same service?
If some service is used for multiple requests, it should implement
either batching or HTTP keepalive should be used, but simulating it
through keeping HTTP connection open when it is supposed to be closed by
the protocol sounds wrong. If you want to keep HTTP connection, why not
just have the client keep it?
> 0.03s user 0.01s system 2% cpu 1.530 total
>
>
> With raphf effectively disabled:
> █ mike@smugmug:~$ time php -d raphf.persistent_handle.limit=0 -r 'for
> ($i=0;$i<20;++$i) {(new http\Client("curl","google"))->enqueue(new
> http\Client\Request("GET", "http://www.google.at/";))->send();}'
>
> 0.04s user 0.01s system 1% cpu 2.790 total
So, the difference is microscopic even here. But with proper HTTP
handling - like batch requests or keepalive - it would be even less.
> The sole code change would be removing the check for POST, i.e.
> `!strcasecmp(SG(request_method),"POST")` so that actually any request
> method with a recognized content-type (i.e. application/form-data or
> application/x-www-form-urlencoded) would trigger standard post data
> handling.
By "standard post data handling" you mean _POST? I'm not sure it's a
good idea - it may lead some applications that assume _POST existence
means POST request into a wrong path, which may have some bad
consequences as GET and POST to the same URL may have completely
different meaning in REST application (e.g. GET may be read and POST may
be write). Why not just let the user ask for data if they need it, but
keep the environment as is for those that do not need it?
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
