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?

> 
> * 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.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to