rfc:pecl_http
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| rfc:pecl_http [2015/01/29 11:13] – typo mike | rfc:pecl_http [2017/09/22 13:28] (current) – external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== PHP RFC: Add pecl_http to core ====== | ====== PHP RFC: Add pecl_http to core ====== | ||
| - | * Version: 2.0 | + | * Version: 2.4 |
| - | * Date: 2015-01-29 | + | * Date: 2014-08-19 |
| + | * Last-Modified: 2015-02-20 | ||
| * Author: Michael Wallner, < | * Author: Michael Wallner, < | ||
| - | * Status: | + | * Status: |
| * First Published at: http:// | * First Published at: http:// | ||
| ===== Introduction ===== | ===== Introduction ===== | ||
| - | It was interesting to see so many “users” that know pecl_http and so many “developers” that had no clue, so let’s start early. | ||
| ==== About ==== | ==== About ==== | ||
| Line 32: | Line 32: | ||
| === Test coverage === | === Test coverage === | ||
| - | The current test suite provides a code coverage of about 90% and is subject to improvement. \\ Coverage resport of v2: http:// | + | The current test suite provides a code coverage of about 90% and is subject to improvement. \\ Coverage resport of v2: http:// |
| There’s one test that currently fails for me due to porting the extension to ZE3, because of reference mismatch and a leak in zend_assign_to_variable_ref() as cause. | There’s one test that currently fails for me due to porting the extension to ZE3, because of reference mismatch and a leak in zend_assign_to_variable_ref() as cause. | ||
| Line 43: | Line 43: | ||
| ===== The Guts ===== | ===== The Guts ===== | ||
| - | A fully merged tree can be inspected here: \\ https:// | + | A fully merged tree can be inspected here (based on v2.2, so slightly out of date): \\ https:// |
| + | |||
| + | An up-to-date (based on v2.3) pecl_http tree for PHP7 can be found here: \\ https:// | ||
| ==== Documentation ==== | ==== Documentation ==== | ||
| Line 55: | Line 57: | ||
| | | ||
| ==== Dependencies ==== | ==== Dependencies ==== | ||
| - | === zlib === | + | === libz AKA zlib === |
| * Type: of dep: hard build dep | * Type: of dep: hard build dep | ||
| * Minimum version: 1.2.0.4 | * Minimum version: 1.2.0.4 | ||
| Line 76: | Line 78: | ||
| * Provided functionality: | * Provided functionality: | ||
| * Current state: nice to have - must have for more parallel requests than select() can reasonably handle; might look into additional alternatives like libuv (libev already has libevent compatibility) | * Current state: nice to have - must have for more parallel requests than select() can reasonably handle; might look into additional alternatives like libuv (libev already has libevent compatibility) | ||
| - | |||
| - | === ext/json === | ||
| - | * Type of dep: soft build dep | ||
| - | * Provided functionality: | ||
| - | * Current state: suspect to removal, please discuss | ||
| - | * Affected code: https:// | ||
| - | |||
| - | === ext/iconv === | ||
| - | * Type of dep: soft build dep | ||
| - | * Provided functionality: | ||
| - | * Current state: suspect to removal, please discuss | ||
| - | * Affected code: https:// | ||
| - | |||
| - | === ext/hash === | ||
| - | * Type of dep: soft build dep | ||
| - | * Provided functionality: | ||
| - | * Current state: suspect to removal, please discuss | ||
| - | * Affected code: https:// | ||
| === pecl/propro === | === pecl/propro === | ||
| Line 365: | Line 349: | ||
| Most of the features are directly accessible through pecl_http' | Most of the features are directly accessible through pecl_http' | ||
| - | === INI === | + | === Globals |
| - | Additionally to the INI setting of raphf, there’s http.etag.mode (USER, defaults to crc32b), defining a hash algo used to generate ETags for dynamic response bodies. It may be better to make this a property of the actual http\Env\Response instead of a global setting, please discuss. | + | Nothing in the global namespace, except |
| - | === RINIT === | + | == Client |
| - | The http\Env module kicks the POST parser regardless of the request method, only the right content type of x-www-form-urlencoded or form-data must be given. | + | * Docs: http://devel-m6w6.rhcloud.com/ |
| + | * Current status: essential | ||
| + | * Related functionality in core: HTTP stream wrapper, ext/curl | ||
| - | I suspect this is a controversial feature, so I’m listing it separately: \\ https:// | + | The HTTP stream wrapper |
| - | The '' | + | Better support for more complicated applications like different authentication schemes, proxy types, encodings, SSL/TLS layers and what not is a desirable out of the box functionality. |
| - | If accepted, it would be easier to ditch this RINIT and just lift the request method limitation. | + | All of that would actually |
| - | === Globals === | + | Currently only libcurl is implemented as a provider for http\Client, providing most of the functionality of most-current libcurl. This should be a good bet, because libcurl is mature and ubiquitously available.This does not mean that we may not implement our own " |
| - | Nothing in the global namespace, except | + | |
| - | == Client | + | http\Client |
| - | http:// | + | |
| - | The http stream wrapper is of limited functionality and the existing libcurl binding is subpar. They could be improved separately, but that is not subject of this RFC. | + | == Encoding == |
| + | * Docs: http:// | ||
| + | * Current status: essential | ||
| + | * Related functionality in core: ext/zlib | ||
| - | Currently only libcurl is implemented as a provider for http\Client, providing most of the functionality | + | Actually ext/zlib supports all the same three encodings since I fixed it a few years ago, so there could be the occasion for few shared code lines. What it definitely lacks, though, are incremental encoders/ |
| - | Representation | + | AFAIK there no accessible implementation |
| - | Support for parallel requests and optional libev{,ent} support. See f.e. http:// | + | == Env == |
| + | * Docs: http:// | ||
| + | * Current status: feature completive | ||
| + | * Related functionality in core: superglobals, | ||
| - | == Cookie == | + | http\Env provides negotiation of content type, character set and language which is a feature set often asked for, nothing comparable exists in core. |
| - | http:// | + | |
| - | Parses Cookie | + | Most of what the environmental/ |
| - | == Encoding == | + | http\Env\Request provides a central access point for all of that data and makes it safe to change/mock it without actually changing the original environment. |
| - | http://devel-m6w6.rhcloud.com/ | + | |
| - | Streamable implementations of chunked | + | http\Env\Response provides features for sending responses beyond header(), ob_start() |
| - | == Env == | + | == Message |
| + | * Docs: http:// | ||
| + | * Current status: essential | ||
| + | * Related functionality in core: rfc1867.c | ||
| - | Negotiation facilities, representations | + | Message parser and tools. http\Message is the base class of all request and response |
| - | Support | + | Also message bodies with support |
| + | |||
| + | Splitting a multipart body creates a chain of http\Message objects. | ||
| == Header == | == Header == | ||
| - | http:// | + | * Docs: http:// |
| + | * Current status: essential | ||
| + | * Related functionionalty in core: non-existent | ||
| Header parser and tools. | Header parser and tools. | ||
| - | == Message == | + | I'm really not sure what case I should make about a header and message parser implementation in an HTTP package. |
| - | http:// | + | |
| - | Message parser and tools. http\Message is the base class of all request and response classes. Note that a " | + | == Cookie == |
| + | * Docs: http:// | ||
| + | * Current status: feature completive, maybe the odd cousin | ||
| + | * Related functionality in core: non-existent | ||
| - | Also message bodies with support for building | + | Cookie |
| - | Splitting a multipart body creates a chain of http\Message objects, see http:// | + | One could argue that there is related functionality in core, namely php_default_treat_data(), |
| == Params == | == Params == | ||
| - | http:// | + | * Docs: http:// |
| + | * Current status: essential | ||
| + | * Related functionality in core: non-existent | ||
| Header params parser; think of a content-type or an accept header. Negotiation, | Header params parser; think of a content-type or an accept header. Negotiation, | ||
| == QueryString == | == QueryString == | ||
| - | http:// | + | * Docs: http:// |
| + | * Current status: feature completive | ||
| + | * Related functionality in core: parse_str() (php_default_treat_data()) | ||
| Query string parser and tools. Actually builds on http\Params. | Query string parser and tools. Actually builds on http\Params. | ||
| + | |||
| + | parse_str() suffers from its legacy/ | ||
| == Url == | == Url == | ||
| - | http:// | + | * Docs: http:// |
| + | * Current status: essential | ||
| + | * Related functionality in core: parse_url() | ||
| - | Ever been hit by the iscntrl() usage of parse_url()? | + | URL parser and tools with UTF-8, locale multibyte and IDNA support |
| - | URL parser and tools with UTF-8, locale multibyte and IDNA support (need to check if, and how much it diverges from IRIs). | + | I'm not sure what recommendation parse_url() follows, if any. |
| ==== Unaffected PHP Functionality ==== | ==== Unaffected PHP Functionality ==== | ||
| Line 444: | Line 449: | ||
| ===== Vote ===== | ===== Vote ===== | ||
| - | 50%+1 combined " | + | Three way " |
| + | |||
| + | <doodle title=" | ||
| + | * Yes, enabled by default | ||
| + | * Yes, disabled by default | ||
| + | * No | ||
| + | </ | ||
| + | |||
| + | \\ | ||
| + | \\ | ||
| + | Additional simple vote on the namespace prefix (" | ||
| + | |||
| + | <doodle title=" | ||
| + | * http | ||
| + | * php\http | ||
| + | </ | ||
| + | |||
| + | ===== Discussed and changed items ===== | ||
| + | |||
| + | == Parsing multipart/ | ||
| + | |||
| + | This functionality was removed from the proposal. | ||
| + | |||
| + | == Parsing a/json into $_POST == | ||
| + | |||
| + | This functionality was removed from the proposal, which removed the ext/json dependency. | ||
| + | |||
| + | == Translating charsets of http\QueryString == | ||
| + | |||
| + | This functionality was removed from the proposal, which removed the ext/iconv dependency. | ||
| + | |||
| + | == Extended hashing methods for ETags of dynamic content == | ||
| + | |||
| + | This functionality was removed from the proposal, which removed the ext/hash dependency. | ||
| + | |||
| + | == Splitting up into smaller RFCs == | ||
| + | |||
| + | It was requested to split this RFC up into more smaller ones, but mainly only, as observed by me, to *not* bring an HTTP client implementation into the default distribution. These requests were not considered further by me, because I think the client gives substantial value to the overall package. | ||
| + | |||
| + | == Upgrade path for existing pecl_http users == | ||
| + | |||
| + | A pecl_http integraded into the default distribution would be considered v3. Upcoming v2 releases could take measures to prepare any transition to the PHP7 API. | ||
| + | |||
| + | == Namespace choice, or the case of the case == | ||
| + | |||
| + | I consider this issue non-important, | ||
| + | |||
| + | There will be an extra vote on whether to prefix the '' | ||
| ===== Changelog ===== | ===== Changelog ===== | ||
| Line 459: | Line 511: | ||
| * 2.0 | * 2.0 | ||
| * Complete rewrite | * Complete rewrite | ||
| + | * 2.1 | ||
| + | * Expanded feature section | ||
| + | * 2.2 | ||
| + | * Removed optional dependencies on all three extensions (json, iconv, hash), and the one INI entry related to it | ||
| + | * 2.3 | ||
| + | * Removed http\Env RINIT section | ||
| + | * Changed namespace from '' | ||
| + | * Fixed some wordings and list formattings | ||
| + | * 2.4 | ||
| + | * Added " | ||
rfc/pecl_http.1422530031.txt.gz · Last modified: 2017/09/22 13:28 (external edit)