2 title: pecl/http update
8 Yeah, you guessed, version 0.23 of
9 [pecl/http](http://pecl.php.net/package/pecl_http) has been released, and it's
10 time for a feature update ;)
14 [http_parse_cookie](http://dev.iworks.at/ext-http/http-functions.html.gz#http_parse_cookie)() has been reimplemented (and
15 HttpRequest::getResponseCookie() has been moved to
16 [HttpRequest::getResponseCookies](http://dev.iworks.at/ext-http/http-functions.html.gz#HttpRequest_getResponseCookies)().
18 original Netscape [draft](http://wp.netscape.com/newsref/std/cookie_spec.html)
19 and the two [cookie](ftp://ftp.rfc-editor.org/in-notes/rfc2109.txt)
20 [RFCs](ftp://ftp.rfc-editor.org/in-notes/rfc2965.txt) it was pretty obvious
21 that the previous implementation was pretty bogus.
23 Now it works as follows:
26 http_parse_cookie("cookie1=value; cookie2=\"1;2;3;4\"; path=/");
48 As you can see, a cookie line can have several name/value pairs. The standard
49 additional fields like expires, path etc. are recogniced automatically. The
50 RFCs, though, define some other standard extra elements, here's where the
51 third parameter of http_parse_cookie() plays in:
54 http_parse_cookie("cookie1=value; cookie2=\"1;2;3;4\"; comment=\"none\"; path=/",
78 If "comment" wouldn't have been specified as an allowed extra element, it
79 would just have been recognized as another cookie.
80 IF you pass HTTP_COOKIE_PARSE_RAW as second parameter to http_parse_cookie(),
81 no urldecoding is performed.
82 The flags in the return value is a bitmask of HTTP_COOKIE_SECURE and
87 Some users pointed me to the fact that neither
88 [HttpMessage](http://dev.iworks.at/ext-http/http-functions.html.gz#HttpMessage)
89 nor [HttpRequest](http://dev.iworks.at/ext-http/http-functions.html.gz#HttpRequest)
90 provide accessors to the HTTP
91 response reason phrase AKA status text. They've been added in form of
92 [HttpMessage::getResponseStatus](http://dev.iworks.at/ext-http/http-functions.html.gz#HttpMessage_getResponseStatus)() and
93 [HttpRequest::getResponseStatus](http://dev.iworks.at/ext-http/http-functions.html.gz#HttpRequest_getResponseStatus)().
95 Some might have wondered why [HttpMessage](http://dev.iworks.at/ext-http/http-functions.html.gz#HttpMessage)s are
96 chained in kind of a reverse order. Well, that has internal reasons, caused by how we retreive the data from
97 [libcurl](http://curl.haxx.se) and how the message parser works. Anyway
98 there's now [HttpMessage::reverse](http://dev.iworks.at/ext-http/http-functions.html.gz#HttpMessage_reverse)()
99 which reorders the messages in a more intuitive chronical way:
102 $msg = new HttpMessage(
108 foreach ($msg as $m) echo $m;
109 foreach ($msg->reverse() as $m) echo $m;
125 Note, though, that [HttpMessage::toString](http://dev.iworks.at/ext-http/http-functions.html.gz#HttpMessage_toString)(true) automatically prepends parent
126 messages, i.e. gives the latter result.
130 For servers that don't urldecode cookies, a new option has been added, named
131 "encodecookies", which omits urlencoding cookies if set to FALSE.
133 Similarily to the "lastmodified" request option, there's now an "etag" option
134 working along the same lines.
136 [HttpRequest::getHistory](http://dev.iworks.at/ext-http/http-functions.html.gz#HttpRequest_getHistory)()
137 now returns a real HttpMessage property, which measn that this message chain is no longer immutable to
138 changes made by the user.
140 If a request fails for some reason, you should now be able to get the error
141 message through [HttpRequest::getResponseInfo](http://dev.iworks.at/ext-http/http-functions.html.gz#HttpRequest_getResponseInfo)("error").