ID: 23740 Comment by: poncha at gmx dot net Reported By: scoop at freshmeat dot net Status: Wont fix Bug Type: HTTP related Operating System: Linux 2.4 PHP Version: 4.3.1 New Comment:
quote from: http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1.1 - 2xx: Success - The action was successfully received, understood, and accepted | "200" ; Section 10.2.1: OK | "201" ; Section 10.2.2: Created | "202" ; Section 10.2.3: Accepted | "203" ; Section 10.2.4: Non-Authoritative Information | "204" ; Section 10.2.5: No Content | "205" ; Section 10.2.6: Reset Content | "206" ; Section 10.2.7: Partial Content which means that *any* 2xx status means successful transaction. The content may be partial, alternative or only notification on the status of the action you request, but still it is quite different from 4xx codes , so you are wrong on the "202 is effectively the same as 404". http 2xx status replies have completely different semantical value. As for the "workaround", i am using curl and fsockopen in other cases, but i consider this point as a misbehavior of php fopen wrappers. NB: 2xx replies are NOT error responses! these are legitimate success replies. Previous Comments: ------------------------------------------------------------------------ [2003-05-21 13:21:40] [EMAIL PROTECTED] Thats correct; 202 is effectively the same as 404, in that both can send back content, but neither of them send back the content that you requested, so fopen() returns false and gives you a warning message. (You can still suppress the warning using the @ operator and inspect $http_response_headers in your script). ------------------------------------------------------------------------ [2003-05-21 12:18:04] scoop at freshmeat dot net But fopen() actually states "failed to create stream" which should not be the case as the connection is being established and there is something being returned by the webserver. As such, it neither returns any resource, it returns FALSE (just as with a 404 error on the server side). PS: The error document returned is valid XML, no worries regarding the XML parser :) PPS: I do know this is possible via fsockopen() and this is the implementation I've been using for years. This behaviour occured to me during debugging excessive hits on the slashdot backend files by a headline grabber. ------------------------------------------------------------------------ [2003-05-21 11:43:43] [EMAIL PROTECTED] file() has the same semantics as fopen() when it comes to dealing with the content of the returned stream. file() also sets $http_response_header. ------------------------------------------------------------------------ [2003-05-21 11:42:00] [EMAIL PROTECTED] We won't change fopen() like this, as the semantics of fopen("http://";) are that it returns the resource you requested, not an explanation of why it didn't come back ;) In your example, it sounds like you are expecting an XML document as the content; what happens when your XML parser falls over the error text? Remember that fopen() sets $http_response_header in the local scope to be the contents of the headers returned by the remote server; you might find this useful. What you can do instead of using fopen() either use the curl extension or use fsockopen() to make the http request yourself. We have some plans for an "easy" streams based http_request() function in PHP5, but nothing definite yet. ------------------------------------------------------------------------ [2003-05-21 11:23:41] scoop at freshmeat dot net When using file() or other streams functions supporting the use of URIs as their parameter the function behaves incorrectly when encountering HTTP Status Code 202. It'd be useful to return the accessed document instead of returning nothing at all and issuing a warning since the document body is likely to include a reason why status code 202 is being returned (as suggested by the RFC). Would it be possible to change that behaviour? Thanks. Example: Warning: file(http://games.slashdot.org/games.rdf) [http://www.php.net/function.file]: failed to create stream: HTTP request failed! HTTP/1.1 202 Accepted Reference: The HTTP RFC 10.2.3 202 Accepted The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this. The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=23740&edit=1
