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
