Re: Package proposal: HTTP_Status

Alexey Borzov wrote:

-1 for the standalone package. I don't quite see the problem it is trying to solve.

It's trying to make it easier to translate status codes, and to check whether they're success, or errors, or whatever. It's also trying to put all of this information in one reusable place, so that updates to the protocols only require one code change.

1) Mapping from response codes to their meanings can easily be done via an array.

Yes, an array that would have to be maintained for every package when changes are made, such as a new version of HTTP or other stuff like WebDAV.

2) Getting the type of response can be done via switch(intval($code / 100)) {

    case 1:
        ...
    case 2:
        $type = 'Success';
        break;
    case 3:
        ...
    case 4:
        ...

} and caring about special cases.

How do you do that? switch(intval($code / 100)) {

     case 1:
         ...
     case 2:
         $type = 'Success';
         break;
     case 3:
         ...
     case 4:
         ...

} if ($code == 304 || $code == 306 || $code < 300 || $code >= 600) { ... } elseif ($code >= 400 && < 600) { ... } I thought we were supposed to be making things easier here...

In HTTP_Client, the following is used to check for redirection: if ( ... in_array($code, array(300, 301, 302, 303, 307))) {

    ... do stuff because it's a redirection ...

} [snip]

It wouldn't be, as 304 is not exactly a redirect and 306 is unused. You are actually proposing an inferior solution.

That's something you'd probably have to argue with the IETF about. All of the redirection codes[1] (including 304![2]) mean that another request needs to be initiated by the user agent. A conditional GET is the only case in which a 304 should be recieved; Since HTTP_Client isn't sending those, I don't think it's an issue. If there are cases where you'd need exceptions, use: if (!in_array($code, array(304, 307)) && HTTP_Status::isRedirection($code)) {

    ...

} -- Marshall Roch [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3 [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5