php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #23740 Incorrect behaviour resulting from HTTP Status Code 202
Submitted: 2003-05-21 11:23 UTC Modified: 2003-05-21 13:21 UTC
Votes:9
Avg. Score:4.7 ± 0.5
Reproduced:9 of 9 (100.0%)
Same Version:1 (11.1%)
Same OS:4 (44.4%)
From: scoop at freshmeat dot net Assigned:
Status: Wont fix Package: HTTP related
PHP Version: 4.3.1 OS: Linux 2.4
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: scoop at freshmeat dot net
New email:
PHP Version: OS:

 

 [2003-05-21 11:23 UTC] 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.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-05-21 11:42 UTC] 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:43 UTC] 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 12:18 UTC] 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 13:21 UTC] wez@php.net
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).
 [2004-10-07 16:39 UTC] poncha at gmx dot net
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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 05:01:28 2024 UTC