Of course, I don't mean a 304 "error" - I mean a 304 response

PHP_4_3: Reproduced with latest CVS, here's some leaks:

/usr/src/web/php/php4/Zend/zend_hash.c(450) :  Freeing 0x086510CC (64 bytes), script=t.php
/usr/src/web/php/php4/Zend/zend_hash.c(416) :  Freeing 0x08651074 (35 bytes), script=t.php
Last leak repeated 8 times
/usr/src/web/php/php4/ext/standard/file.c(616) :  Freeing 0x086505AC (44 bytes), script=t.php
/usr/src/web/php/php4/Zend/zend_variables.c(122) : Actual location (location was relayed)
/usr/src/web/php/php4/ext/standard/file.c(997) :  Freeing 0x08650494 (44 bytes), script=t.php
/usr/src/web/php/php4/Zend/zend_API.c(562) : Actual location (location was relayed)
/usr/src/web/php/php4/ext/standard/http_fopen_wrapper.c(372) :  Freeing 0x08650EAC (25 bytes), script=t.php
Last leak repeated 7 times
/usr/src/web/php/php4/ext/standard/http_fopen_wrapper.c(370) :  Freeing 0x08650E6C (12 bytes), script=t.php
Last leak repeated 7 times
/usr/src/web/php/php4/ext/standard/http_fopen_wrapper.c(316) :  Freeing 0x086502F4 (18 bytes), script=t.php
/usr/src/web/php/php4/ext/standard/http_fopen_wrapper.c(296) :  Freeing 0x086502B4 (12 bytes), script=t.php
/usr/src/web/php/php4/Zend/zend_hash.c(188) :  Freeing 0x0864DD1C (32 bytes), script=t.php
/usr/src/web/php/php4/ext/standard/file.c(614) :  Freeing 0x0864DC9C (12 bytes), script=t.php
/usr/src/web/php/php4/main/streams.c(2884) :  Freeing 0x08652A44 (57 bytes), script=t.php
/usr/src/web/php/php4/Zend/zend_variables.c(111) : Actual location (location was relayed)
/usr/src/web/php/php4/main/streams.c(2882) :  Freeing 0x08652A04 (12 bytes), script=t.php

Seems to work with HEAD, but still some leaks:

/usr/src/web/php/php5/main/streams/streams.c(1694) :  Freeing 0x40E49B98 (57 bytes), script=t.php
/usr/src/web/php/php5/Zend/zend_variables.c(137) : Actual location (location was relayed)
/usr/src/web/php/php5/main/streams/streams.c(1692) :  Freeing 0x40E49B54 (16 bytes), script=t.php
=== Total 2 memory leaks detected ===

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

The memory leak is not fixed. After the fix the script works as expected, fopen() fails because the return code is 304 (what you wanted) and not 200.

IN fact, downloading the most recent snap and fixing the install error (which is an RCS comment) - it still produces the same result.

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

The reason that functions using $fp subsequent to fopen() fails is because fopen() itself had failed and $fp === false.

This 5.0 error suggests an error in the resource creation that is not reported by the fopen.

I test for the error - the resource creation returns true from fopen

I lied. false is returned by fopen.

However, fopen succeeds without the context and fails with it.

In the 4.3 snap fopen succeeds but does not produce the desired result.

This bug continues and is not bogus

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

PHP4 was missing certain context features that prevented it from sending any context headers other then user_agent. This is now fixed.

Now in both PHP5 & PHP4 fopen() fails due to 304 response code.

My thanks. 

I will confirm with the latest snap. Someone should document this 304 behavior - it is very useful.

A footnote here. 

I am concerned that this behavior does not distinquish between a "If-Modified-Since" 304 and an honest to goodness error (e.g., a "Not Found" uri).  

The designers might consider some means to recover the response/error or a modification of this behavior. Let me know.

RTM:
http://uk.php.net/manual/en/wrappers.php
search for $http_response_header

Ah, but if this is the case then 

stream_get_meta_data

should not fail after the resource fails - which the above example shows it does.

I can confirm that is now behaves as specified in this report, if not as expected :), in the php4-STABLE-200311282030 build - however, I urge a review of this behavior.

Formally there is a clear distinction between correct behavior in response to an "If-Modified-Since" and a failure that results from and invalid URI.

In addition, stream_get_meta_data( resource ) should be consistent with $http_response_header. Currently  stream_get_meta_data fails if the resource failed - I suggest that it should report the details of the stream state - including a failure.

While the pragmatics of having fopen return false for a 304 are good - I suggest that this is in fact incorrect semantics - fopen succeeded and therefore, formally, should return true.