headers not passed in stream context

Bug #26440

Submitted:

2003-11-27 17:03 UTC

Modified:

2003-11-28 16:49 UTC

Votes:	3
Avg. Score:	5.0 ± 0.0
Reproduced:	0 of 0 (0.0%)

From:

steven at pearavenue dot com

Assigned:

pollita (profile)

Status:

Closed

Package:

HTTP related

PHP Version:

4.3.4

OS:

Linux

Private report:

CVE-ID:

None

[2003-11-27 17:03 UTC] steven at pearavenue dot com

Description:
------------
Context passed to fopen does not appear to include header in request.

Reproduce code:
---------------
$uri  = 'http://www.what-it-all-means.com/index.rdf';

$agent = "First-Say-RSS-AGGREGATOR/0.0.2.4 http://www.firstsay.net";
$since = 'Thu, 27 Nov 2003 06:03:08 GMT';
$etag = '"7051a-36a7-3fc5939c"';
$opts = array(
              'http' => array(
                  'method' => "GET",
                  'header' => "If-None-Match: $etag\r\n".                                                                         
                              "If-Modified-Since: $since\r\n",
                  'user_agent' => $agent
                      )
              );

$context = stream_context_create($opts);


$fp = @fopen($uri, 'rb', false, $context);
if (!is_resource($fp)) {
  echo "error";
}
var_dump(stream_context_get_options($fp) );
echo "\n:::::\n";
var_dump ( stream_get_meta_data($fp) );

fclose($fp);


Expected result:
----------------
With the appropriate URL, http-date and etag (you may have to change those above) this should produce a 304 error 

Actual result:
--------------
produces a 200, as though the header is ignored.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

[2003-11-27 17:10 UTC] steven at pearavenue dot com

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

[2003-11-27 18:11 UTC] sniper@php.net

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 ===

[2003-11-27 18:59 UTC] iliaa@php.net

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.

[2003-11-28 12:52 UTC] steven at pearavenue dot com

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

[2003-11-28 13:05 UTC] iliaa@php.net

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.

[2003-11-28 13:06 UTC] steven at pearavenue dot com

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

[2003-11-28 13:08 UTC] steven at pearavenue dot com

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

[2003-11-28 13:13 UTC] steven at pearavenue dot com

I lied. false is returned by fopen.

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

[2003-11-28 13:15 UTC] steven at pearavenue dot com

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

[2003-11-28 13:17 UTC] steven at pearavenue dot com

This bug continues and is not bogus

[2003-11-28 13:49 UTC] iliaa@php.net

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.

[2003-11-28 13:57 UTC] steven at pearavenue dot com

My thanks. 

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

[2003-11-28 14:04 UTC] steven at pearavenue dot com

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.

[2003-11-28 14:47 UTC] steven at pearavenue dot com

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.

[2003-11-28 16:49 UTC] steven at pearavenue dot com

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.