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.

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.

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.

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).

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.