#23740 [WFx]: Incorrect behaviour resulting from HTTP Status Code 202
| From: | wez@php.net | Date: | Wed, 21 May 2003 18:21:41 +0000 |
| Subject: | #23740 [WFx]: Incorrect behaviour resulting from HTTP Status Code 202 | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-40149@lists.php.net to get a copy of this message | ||
ID: 23740
Updated by: wez@php.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:
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).
Previous Comments:
------------------------------------------------------------------------
[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] wez@php.net
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] wez@php.net
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