# $http_response_header - Thread: https://externals.io/message/79360 - Original archive: https://news-web.php.net/php.internals/79360 - Started by Ralph Schindler on 2014-12-01T22:28:04+00:00 - Messages: 18 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #79360 — Ralph Schindler — 2014-12-01T22:28:04+00:00 URL: https://externals.io/message/79360#79360 Hi all, Many of you know from reading the subject line whats coming next! ;) In php, after we interact with HTTP streams (as a client), PHP conjures into local scope a variable with header information from the previous request $http_response_header. Is this behavior something we want to keep around into PHP 7? Or should we find a different/short-cut way to get the information. Currently, the same information can be ascertained, but only if there is an open file handle and only through stream_get_meta_data($fh). It would be nice if there were an as-easy approach to getting data without perhaps conjuring magic variables into the beloved local scope? Thoughts? Ralph Schindler PS Also, do we have any other local-scope variables like this? --- ## #79365 — Rowan Collins — 2014-12-02T00:08:39+00:00 URL: https://externals.io/message/79360#79365 · In reply to: #79360 >Hi all, > >Many of you know from reading the subject line whats coming next! ;) > >In php, after we interact with HTTP streams (as a client), PHP conjures > >into local scope a variable with header information from the previous >request $http_response_header. Is this behavior something we want to >keep around into PHP 7? Or should we find a different/short-cut way to >get the information. > >Currently, the same information can be ascertained, but only if there >is >an open file handle and only through stream_get_meta_data($fh). > >It would be nice if there were an as-easy approach to getting data >without perhaps conjuring magic variables into the beloved local scope? > >Thoughts? >Ralph Schindler > >PS Also, do we have any other local-scope variables like this? Wow, I had no idea that existed; what an incredibly ugly implementation. Even the name is weird (why "header" singular when it contains an array of headers?) The only other local-scope variable listed next to it in the manual [1] is $php_errormsg, which has to be enabled with an ini setting. If the information is useful at all, then I guess a get_last_http_response_headers() function would be less magic - although that would presumably mean the data had to be stashed indefinitely in an internal global just in case it was asked for, rather than it naturally falling out of scope. We could just say that if you're using a shortcut like file_get_contents, you can't have it both ways and access metadata afterwards. It's just a pity ext/curl is so faithful to the underlying lib, and therefore so awkward to use for simple cases. [1]: http://php.net/manual/en/reserved.variables.php --- ## #79368 — Tom Samplonius — 2014-12-02T05:01:06+00:00 URL: https://externals.io/message/79360#79368 · In reply to: #79365 > > Wow, I had no idea that existed; what an incredibly ugly implementation. Even the name is weird (why "header" singular when it contains an array of headers?) Actually, no. HTTP responses contain a single header at the protocol level, but contain multiple lines. At some point, people started to each line a “header”, which is actually more strange. I think that usage may have originated in PHP, actually. At this point, common usage supports both “header” and “headers”, though “header” is the more general term. For comparison, no one refers to the separate fields of a TCP header, as “headers”. Tom --- ## #79370 — Sanford Whiteman — 2014-12-02T05:44:19+00:00 URL: https://externals.io/message/79360#79370 · In reply to: #79368 > I think that usage may have originated in PHP, actually. Eh, dunno about that... http://lists.w3.org/Archives/Public/ietf-http-wg-old/1995SepDec/0277.html for example. Even some W3C specs use "header" instead of the more accurate "header field" so it's kind of a done deal. -- S. --- ## #79376 — Ferenc Kovacs — 2014-12-02T10:28:20+00:00 URL: https://externals.io/message/79360#79376 · In reply to: #79365 On Tue, Dec 2, 2014 at 1:08 AM, Rowan Collins wrote: > On 1 December 2014 22:28:04 GMT, Ralph Schindler > wrote: > > […] > > Wow, I had no idea that existed; what an incredibly ugly implementation. > Even the name is weird (why "header" singular when it contains an array of > headers?) > > The only other local-scope variable listed next to it in the manual [1] is > $php_errormsg, which has to be enabled with an ini setting. > > If the information is useful at all, then I guess a > get_last_http_response_headers() function would be less magic - although > that would presumably mean the data had to be stashed indefinitely in an > internal global just in case it was asked for, rather than it naturally > falling out of scope. > > We could just say that if you're using a shortcut like file_get_contents, > you can't have it both ways and access metadata afterwards. It's just a > pity ext/curl is so faithful to the underlying lib, and therefore so > awkward to use for simple cases. > > [1]: http://php.net/manual/en/reserved.variables.php > > +1 on introducing the get_last function, and I would also suggest adding a new ini settings similarly to track_errors so we can discourage/deprecate the usage of this feature before removing it. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #79380 — Rowan Collins — 2014-12-02T11:04:33+00:00 URL: https://externals.io/message/79360#79380 · In reply to: #79368 Tom Samplonius wrote on 02/12/2014 05:01: > > […] > > Actually, no. HTTP responses contain a single header at the > protocol level, but contain multiple lines. At some point, people > started to each line a “header”, which is actually more strange. I > think that usage may have originated in PHP, actually. At this point, > common usage supports both “header” and “headers”, though “header” is > the more general term. For comparison, no one refers to the separate > fields of a TCP header, as “headers”. I'm not sure the standards back you up on that, actually: RFC 2616 (the old HTTP/1.1 spec obsoleted earlier this year) says: > Request (section 5) and Response (section 6) messages use the generic message format of RFC 822 [9] for transferring entities > (the payload of the message). Both types of message consist of a start-line, zero or more header fields (also known as "headers"), > an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields, and possibly a message-body. Searching for "header" in RFC 822 (dated 1982!), the first mention is this: > The syntax of several fields of the rigidly-formated > ("headers") section is defined in this specification; some of > these fields must be included in all messages. So it looks to me like "HTTP header" has always been a synonym for "HTTP header field" basically forever. The new RFC 7230 uses slightly different wording and references, but still takes "header" to mean "header field", not the whole section: > All HTTP/1.1 messages consist of a start-line followed by a sequence > of octets in a format similar to the Internet Message Format > [RFC5322]: zero or more header fields (collectively referred to as > the "headers" or the "header section"), an empty line indicating the > end of the header section, and an optional message body. -- Rowan Collins [IMSoP] --- ## #81617 — Ferenc Kovacs — 2015-02-02T17:19:03+00:00 URL: https://externals.io/message/79360#81617 · In reply to: #79376 > > > On Tue, Dec 2, 2014 at 1:08 AM, Rowan Collins > wrote: > > > […] > +1 on introducing the get_last function, and I would also suggest adding a > new ini settings similarly to track_errors so we can discourage/deprecate > the usage of this feature before removing it. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu > bump. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #81699 — Julien Pauli — 2015-02-03T09:33:57+00:00 URL: https://externals.io/message/79360#81699 · In reply to: #81617 > > > > […] > of > > […] > file_get_contents, > > […] > a > > […] > > bump. > > Hey. About $php_errormsg , we have `error_get_last()`. About $http_response_headers, we have no replacement. Why not get rid of both ? I mean, those variables magically appearing into your code are born from C, where libc usually give access to errno and errstr variables (which are often implemented as macros). As we are cleaning PHP and reorganizing it for PHP7, I simply would suggest to drop support for anything like automatic magic variable appearence. $HTTP_RAW_POST_DATA could as well disappear (made deprecated as of 5.6). Julien.P --- ## #81700 — Ferenc Kovacs — 2015-02-03T09:38:58+00:00 URL: https://externals.io/message/79360#81700 · In reply to: #81699 > > > > […] > Hey. > > About $php_errormsg , we have `error_get_last()`. > About $http_response_headers, we have no replacement. > > Why not get rid of both ? > I mean, those variables magically appearing into your code are born from > C, where libc usually give access to errno and errstr variables (which are > often implemented as macros). > > As we are cleaning PHP and reorganizing it for PHP7, I simply would > suggest to drop support for anything like automatic magic variable > appearence. $HTTP_RAW_POST_DATA could as well disappear (made deprecated as > of 5.6). > > Julien.P > yeah, as I mentioned I support introducing a new function for fetching the info, but I'm a bit hesitant to remove these variables before we start deprecating them both in the manual and at least the ini usage. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #81720 — Ralph Schindler — 2015-02-03T15:08:10+00:00 URL: https://externals.io/message/79360#81720 · In reply to: #81699 > > About $php_errormsg , we have `error_get_last()`. > About $http_response_headers, we have no replacement. Well, we sort of do. You can get header information from the http context stream metadata: $fh = fopen($urlPath, 'r', false, $context); $metadata = stream_get_meta_data($fh); $content = stream_get_contents($fh); fclose($fh); $metadata['wrapper_data'] will include the headers. From an ease-of-use standpoint, $http_reponse_header gives you immediate access to headers when the previous operation was a stream based HTTP request (via fopen, or even `file_get_contents()`). > Why not get rid of both ? > I mean, those variables magically appearing into your code are born from C, > where libc usually give access to errno and errstr variables (which are > often implemented as macros). We could, but it would be nice to add some kind of easy to use replacement for the "last stream operation", which essentially is the best/most common use case for $http_response_header after the fact that it is magically conjured into local scope. For example, right now, to get headers from a http stream request, its as ease as: $content = file_get_contents('http://php.net/'); var_dump($http_response_header); I think a nice replacement for that would be supporting (at least): $content = file_get_contents('http://php.net/'); $header = `stream_get_meta_data()`['wrapper_data']; By passing null to `stream_get_meta_data()`, it would use metadata from the last request made with streams (in the same way $http_response_header is allocated). Thats just a thought for that. I no other suggestion for the error stuff as I'd forgotten that even existed. -ralph --- ## #81722 — Michael Wallner — 2015-02-03T15:22:07+00:00 URL: https://externals.io/message/79360#81722 · In reply to: #81699 > > > $HTTP_RAW_POST_DATA could as well disappear (made deprecated as of 5.6). > This is already gone in master, which reminds me of the missing UPGRADING note. Regards, Mike --- ## #81769 — Stanislav Malyshev — 2015-02-04T06:42:19+00:00 URL: https://externals.io/message/79360#81769 · In reply to: #81699 Hi! > About $php_errormsg , we have `error_get_last()`. > About $http_response_headers, we have no replacement. > > Why not get rid of both ? I agree. Magically appearing variables are bad design and if we can get rid of them, PHP 7 is the time. -- Stas Malyshev smalyshev@gmail.com --- ## #85505 — Ferenc Kovacs — 2015-03-27T13:20:21+00:00 URL: https://externals.io/message/79360#85505 · In reply to: #81769 On Wed, Feb 4, 2015 at 7:42 AM, Stanislav Malyshev wrote: > Hi! > > > […] > > I agree. Magically appearing variables are bad design and if we can get > rid of them, PHP 7 is the time. > > -- > Stas Malyshev > smalyshev@gmail.com > did we miss the opportunity? -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #85510 — Ralph Schindler — 2015-03-27T16:42:01+00:00 URL: https://externals.io/message/79360#85510 · In reply to: #85505 > > […] > > did we miss the opportunity? Maybe so. Truthfully, I came to the conclusion I did not want to propose removing $http_response_header unless we had a reasonable replacement for the somewhat common workflow of file_get_contents('http://...'); then usage of $http_response_header. I think there might be room to have added http_get_last_header(), or something to that effect. -ralph --- ## #85511 — Ferenc Kovacs — 2015-03-27T16:50:38+00:00 URL: https://externals.io/message/79360#85511 · In reply to: #85510 On Fri, Mar 27, 2015 at 5:42 PM, Ralph Schindler wrote: > > About $php_errormsg , we have `error_get_last()`. > > […] > > Maybe so. Truthfully, I came to the conclusion I did not want to propose > removing $http_response_header unless we had a reasonable replacement for > the somewhat common workflow of file_get_contents('http://...'); then > usage of $http_response_header. > > I think there might be room to have added http_get_last_header(), or > something to that effect. > > yeah, but we already mentioned/discussed this that the removal would require introducing another way (eg. adding a method) for fetching the headers. I think that introducing this method can happen in a minor version(without removing the $http_response_header variable), so I will create a pull request and ask Julien about including it in 5.5 and upwards. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #85512 — Rowan Collins — 2015-03-27T18:12:45+00:00 URL: https://externals.io/message/79360#85512 · In reply to: #85511 Ferenc Kovacs wrote on 27/03/2015 16:50: > yeah, but we already mentioned/discussed this that the removal would > require introducing another way (eg. adding a method) for fetching the > headers. > I think that introducing this method can happen in a minor version(without > removing the $http_response_header variable), so I will create a pull > request and ask Julien about including it in 5.5 and upwards. I've seen comments to this effect before, and don't really understand the motivation for adding functions in patch versions. Personally, I'd never rely on such a function, because it would mean my code relied on a version spec like "(>= 5.5.23 && < 5.6.0) || >= 5.6.7", which is just horrible. And on the negative side, there's the (admittedly very small) possibility of unexpectedly colliding with someone's existing function. The definition at SemVer.org (I know PHP doesn't officially follow this definition, but it's a well-thought out point of reference) makes clear: > Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. Isn't it enough if the new function, and the deprecation of the variable, is snuck into 7.0, or added in 7.1? Regards, -- Rowan Collins [IMSoP] --- ## #85514 — Ferenc Kovacs — 2015-03-27T21:08:04+00:00 URL: https://externals.io/message/79360#85514 · In reply to: #85512 On Fri, Mar 27, 2015 at 7:12 PM, Rowan Collins wrote: > Ferenc Kovacs wrote on 27/03/2015 16:50: > > > […] > > I've seen comments to this effect before, and don't really understand the > motivation for adding functions in patch versions. Personally, I'd never > rely on such a function, because it would mean my code relied on a version > spec like "(>= 5.5.23 && < 5.6.0) || >= 5.6.7", which is just horrible. > In general this is because we used to do this and because our releaseprocess rfc allows it. In this specific case I have a couple of reasons to not wait for the next minor: 1, 5.7 got voted down, so the next minor will be probably 7.1 and that is like 1.5-2 years in the future, depending on how much if any delay the 7.0 gets. 2, I could try to argue that this doesn't require an RFC and target 7.0 regardless of the feature freeze (which technically wouldn't be any more risky than targetting 5.5/5.6 and simply merging up) but that would probably cause drama and people would use it as precedence to try to get bigger/more destabilizing changes into 7.0. 3, just bumped into this issue today myself (and the lack of option to elegantly pass context options to `get_headers()` aka https://bugs.php.net/bug.php?id=55716 planning to send a PR for that one too) and seeing how fell under the radar I tried to see what I can do. > > And on the negative side, there's the (admittedly very small) possibility > of unexpectedly colliding with someone's existing function. > yeah, that is always a possibility, usually this is why we look around on google/github to avoid the common collisions, but technically we don't consider this BC break in a sense that it is still allowed by the releaseprocess RFC. > > The definition at SemVer.org (I know PHP doesn't officially follow this > definition, but it's a well-thought out point of reference) makes clear: > > > […] > compatible functionality is introduced to the public API. > agree, albeit people rarely follow that properly: http://massalabs.com/dev/2014/03/12/battle-of-semver.html which is somewhat defeats the original idea. > > Isn't it enough if the new function, and the deprecation of the variable, > is snuck into 7.0, or added in 7.1? > that would be the safest option, I just don't think that in this specific case there are much risk doing it in a micro. if it turns out that we have a general consensus about changing our ways, I would support it (as you can find a bunch of mails/threads from me on this topic on this list), I just don't think that it is a good idea that sometimes we allow this to happen without anybody saying a word, and sometimes when don't. we should make up our mind and stick to it whatever we end up deciding. --- ## #85517 — Yasuo Ohgaki — 2015-03-27T23:11:18+00:00 URL: https://externals.io/message/79360#85517 · In reply to: #81769 Hi all, On Wed, Feb 4, 2015 at 3:42 PM, Stanislav Malyshev wrote: > > […] > > I agree. Magically appearing variables are bad design and if we can get > rid of them, PHP 7 is the time. +1 -- Yasuo Ohgaki yohgaki@ohgaki.net