Hi Stas!
On 05/02/15 00:43, Stanislav Malyshev wrote:
> Hi!
>
>> Points explicitely marked for discussion in the RFC itself:
>>
>> * pecl/propro
>> Proxies for properties representing state in internal C structs
>> https://wiki.php.net/rfc/pecl_http#peclpropro
>>
>> * pecl/raphf
>> (Persistent) handle management within objects instead of resources
>> https://wiki.php.net/rfc/pecl_http#peclraphf
>> Also, take special note of the INI setting:
>> https://wiki.php.net/rfc/pecl_http#raphf_ini_setting
>
> I'm still not sure why we need these two, to be frank. E.g., for the
> former I can kind of get it, though I don't see any use-case that really
> requires going to such lengths, for the latter I'm not even sure what
> the case for that is - i.e., why exactly would one need persistent HTTP
> connections surviving the request?
Uh, for me it's actually the reverse :) While propro is nice to have, I
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
HTTP APIs are so common nowadays.
Compare the timings accessing google 20 times sequentually:
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();}'
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
>
>>
>> * POST parsing disregarding request method, solely based on content-type
>> https://wiki.php.net/rfc/pecl_http#rinit
>
> I'm not sure what exactly happens there. Is _POST in the RFC code
> populated for every kind of request automatically? That may be
> unexpected, though the ability to parse incoming data as POST regardless
> of method may be useful. But it'd help to have a description of what
> exactly changes.
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.
The RINIT of the http_env module would be removed in any way, because if
this behaviour is accepted, it's accompplished by the change described
above, and if not it makes no sense to keep for an extension bundled
with the core and maybe enabled by default.
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
