Bug #53444 [Bgs->ReO]: get_headers and $http_response_header returns unusable formatting

Edit report at http://bugs.php.net/bug.php?id=53444&edit=1 ID: 53444 Updated by: hm2k@php.net Reported by: hm2k@php.net Summary: get_headers and $http_response_header returns unusable formatting -Status: Bogus +Status: Re-Opened Type: Bug Package: Streams related PHP Version: 5.3.3 Block user comment: N Private report: N New Comment: The standard bug resolution protocol is to close a bug once both parties agree the issue is resolved, if not, the bug may be reopened until it is resolved. Again, you should address this issue. Re-opened. Previous Comments: ------------------------------------------------------------------------ [2010-12-13 12:43:18] aharvey@php.net I'm pretty sure Ilia intended that as a rhetorical question. hm2k, please don't reopen bugs that have been closed by a core developer just because you disagree with the resolution. It's not the first time you've done it, and to be honest, combined with the constant questioning of whether the triager/assignee is doing the right thing, it's pretty unfriendly. ------------------------------------------------------------------------ [2010-12-13 12:17:15] hm2k@php.net Firstly, iliaa you need to learn how to correctly manage bugs. You don't just set them to bogus if you're expecting feedback. I can see that you're expecting feedback as you have asked a question. To answer your question: if you have tried to use these headers for anything useful, you will see that it's impossible to properly distinguish which header is from which request. For example, in the "get_headers format with keys" test, there is absolutely no way to be sure which request returned the values in [Set-Cookie], you can only assume or guess. Another example, with the $http_response_header format, there is no finite way to distinguish one set of responses from another, you can only guess by separating by the status line, however if the headers were poisoned it would render this technique useless. In summary, the formats in which the headers are returned is unusable. The ideal solution would be to separate the headers as they are gathered, giving clear boundaries where one ends and another starts. This should be done natively. ------------------------------------------------------------------------ [2010-12-12 19:40:42] 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 What about the formatting is unusable? In the event of multiple headers the returned values are arrays representing elements of duplicate headers... This is the intended functionality. ------------------------------------------------------------------------ [2010-12-11 19:40:45] hm2k@php.net I am aware of the reason I am seeing multiple headers. Multiple headers are what I am expecting. I am aware that the URL is redirecting (as per bug #50719), following redirects is what I am expecting. The issue here is the formatting which is unusable. You should address this issue. ------------------------------------------------------------------------ [2010-12-11 16:16:27] 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 you get multiple headers is because the website you are trying to access is redirecting the URL and by default the headers from all requests are being returned. If you don't want redirects to be followed, set the stream context parameter max_redirects to 0. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=53444 -- Edit this bug report at http://bugs.php.net/bug.php?id=53444&edit=1