php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #26440 headers not passed in stream context
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: No CVE-ID: None
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
33 + 48 = ?
Subscribe to this entry?

 
 [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:38 UTC] wez@php.net
RTM:
http://uk.php.net/manual/en/wrappers.php
search for $http_response_header
 [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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 14 10:01:28 2024 UTC