php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #60584 headers_list() should return in a `$key => $value` fashion
Submitted: 2011-12-21 12:34 UTC Modified: 2011-12-21 15:56 UTC
From: toms at mindboiler dot lv Assigned:
Status: Wont fix Package: Network related
PHP Version: Irrelevant OS: CentOS 2.6.18-274.12.1.el5xen
Private report: No CVE-ID: None
 [2011-12-21 12:34 UTC] toms at mindboiler dot lv
Description:
------------
The function headers_list() returns the headers in a numeric array fashion, 
although, headers are, AFAIK, always in a `Key: Value` fashion, therefore, 
associative array would be a better choice.

More on this, header_remove() works by simply passing the key, therefore, in 
background, headers have their key representation, I suppose.

I've made an example function that uses this function, for a header lookup, but 
ends up in "lots of lines" compared to what could be replaced with one: 
https://gist.github.com/1505803

P.S. This is my first file in PHP Bugs section, please guide me if I have given 
not enough information.

Test script:
---------------
header('Test-Header: A random result');
var_dump(headers_list());

Expected result:
----------------
array(5) {
  ["X-Powered-By"]=>
  string(23) "PHP/5.3.3"
  ["Expires"]=>
  string(38) "Thu, 19 Nov 1981 08:52:00 GMT"
  ["Cache-Control"]=>
  string(77) "no-store, no-cache, must-revalidate, post-check=0, pre-check=0"
  ["Pragma"]=>
  string(16) "no-cache"
  ["Test-Header"]=>
  string(28) "A random result"
}

Actual result:
--------------
array(5) {
  [0]=>
  string(23) "X-Powered-By: PHP/5.3.3"
  [1]=>
  string(38) "Expires: Thu, 19 Nov 1981 08:52:00 GMT"
  [2]=>
  string(77) "Cache-Control: no-store, no-cache, must-revalidate, post-check=0, 
pre-check=0"
  [3]=>
  string(16) "Pragma: no-cache"
  [4]=>
  string(28) "Test-Header: A random result"
}

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-12-21 12:37 UTC] toms at mindboiler dot lv
Changed the summary a little, OS version.
 [2011-12-21 12:37 UTC] toms at mindboiler dot lv
-Summary: headers_list should return in a key => value fashion +Summary: headers_list() should return in a `$key => $value` fashion -Operating System: CentOS 2.6.18 +Operating System: CentOS 2.6.18-274.12.1.el5xen
 [2011-12-21 15:56 UTC] cataphract@php.net
While I don't think HTTP allows repeated headers, they're common in the wild, so key => value is not an option (maybe if the value was an array, but in any case both options break backwards compatibility).

Thank you for the suggestion, anyway.
 [2011-12-21 15:56 UTC] cataphract@php.net
-Status: Open +Status: Wont fix
 [2011-12-22 02:27 UTC] anon at anon dot anon
This could not work. Each sent cookie in an HTTP response has its own Set-Cookie header, and there is no syntax accepted by browsers for combining them into one (separators like commas or semi-colons already have other meanings in the Set-Cookie syntax). Blame Netscape for coming up with that, but 17 years later there's nothing that can be done about it.

Example:

setcookie('foo', 'bar');
setcookie('abc', '123');

var_dump(headers_list());

Output:

array(2) {
  [0]=>
  string(19) "Set-Cookie: foo=bar"
  [1]=>
  string(19) "Set-Cookie: abc=123"
}

See also: http://curl.haxx.se/rfc/cookie_spec.html
 [2011-12-22 08:53 UTC] toms at mindboiler dot lv
For repeated headers you can always use multidimensional array. It wouldn't be 
deeper than two levels anyways.

Like:
array(5) {
  ["X-Powered-By"]=>
  string(23) "PHP/5.3.3"
  ["Expires"]=>
  string(38) "Thu, 19 Nov 1981 08:52:00 GMT"
  ["Cache-Control"]=>
  string(77) "no-store, no-cache, must-revalidate, post-check=0, pre-check=0"
  ["Pragma"]=>
  string(16) "no-cache"
  ["Test-Header"]=>
  string(28) "A random result"
  ["Set-Cookie"]=>
  array(2) {
    [0]=>
    string(7) "foo=bar"
    [1]=>
    string(7) "abc=123"
  }
}

Or, since Cookies are pretty predictable, associate them to keys too, or 
headers_list($flags) and add specific headers flags.

But, yes... The evilness of backwards compatibility, that ruins future 
functionality.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Oct 10 18:01:28 2024 UTC