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?
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 SchindlerPS 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.
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
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.
Tom Samplonius wrote on 02/12/2014 05:01:
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”.
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]
On Tue, Dec 2, 2014 at 1:08 AM, Rowan Collins rowan.collins@gmail.com
wrote:
On 1 December 2014 22:28:04 GMT, Ralph Schindler ralph@ralphschindler.com
wrote: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 SchindlerPS 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 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
On Tue, Dec 2, 2014 at 1:08 AM, Rowan Collins rowan.collins@gmail.com
wrote:On 1 December 2014 22:28:04 GMT, Ralph Schindler <
ralph@ralphschindler.com> wrote: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 SchindlerPS 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 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
On Tue, Dec 2, 2014 at 1:08 AM, Rowan Collins rowan.collins@gmail.com
wrote:On 1 December 2014 22:28:04 GMT, Ralph Schindler <
ralph@ralphschindler.com> wrote: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 SchindlerPS 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 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.hubump.
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
On Tue, Dec 2, 2014 at 1:08 AM, Rowan Collins rowan.collins@gmail.com
wrote:On 1 December 2014 22:28:04 GMT, Ralph Schindler <
ralph@ralphschindler.com> wrote: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
conjuresinto 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 SchindlerPS 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 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.hubump.
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
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
$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
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
On Wed, Feb 4, 2015 at 7:42 AM, Stanislav Malyshev smalyshev@gmail.com
wrote:
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
did we miss the opportunity?
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
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.comdid 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
On Fri, Mar 27, 2015 at 5:42 PM, Ralph Schindler ralph@ralphschindler.com
wrote:
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.comdid 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.
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
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]
On Fri, Mar 27, 2015 at 7:12 PM, Rowan Collins rowan.collins@gmail.com
wrote:
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.
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:Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards
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.
Hi all,
On Wed, Feb 4, 2015 at 3:42 PM, Stanislav Malyshev smalyshev@gmail.com
wrote:
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.
+1
--
Yasuo Ohgaki
yohgaki@ohgaki.net