Hi,
Currently, if you open an HTTP stream using fopen(), and then call
stream_get_meta_data() on it, you obtain an associative array within
which as another with the key 'wrapper_data'. Inside that, there is a
list of the HTTP headers from the server response. I'd like to make this
a little more useful as currently I don't believe there's a way to get
the response code from the remote end without parsing those headers
yourself. While this isn't hard, I'd like to make the following changes:
- move the current contents of the wrapper_data array to a key called
'headers' within wrapper_data; - Add a 'response_code' key, with the server response code as an integer
- Optionally, add things like the mime type of the response.
Anyone got any thoughts on this? I appreciate it'd be a BC break, but I
think it might be useful.
--
Cheers,
Michael
Hi!
Hi,
Currently, if you open an HTTP stream usingfopen(), and then call
stream_get_meta_data()on it, you obtain an associative array within
which as another with the key 'wrapper_data'. Inside that, there is a
list of the HTTP headers from the server response. I'd like to make this
a little more useful as currently I don't believe there's a way to get
the response code from the remote end without parsing those headers
yourself. While this isn't hard, I'd like to make the following changes:
- move the current contents of the wrapper_data array to a key called
'headers' within wrapper_data;
This means breaking every script in existence that uses this data now.
Probably not a good idea. Maybe we should think about a BC way to do the
same.
- Add a 'response_code' key, with the server response code as an integer
- Optionally, add things like the mime type of the response.
Anyone got any thoughts on this? I appreciate it'd be a BC break, but I
think it might be useful.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
- move the current contents of the wrapper_data array to a key called
'headers' within wrapper_data;This means breaking every script in existence that uses this data now.
Probably not a good idea. Maybe we should think about a BC way to do the
same.
Yeah; I'm open to suggestions on that front. I couldn't really think of
another way to do it.
The same data also ends up in the bizarre $http_response_headers var
that gets spontaneously created in local scope - I've wondered about how
good that is to do.
--
Cheers,
Michael
Hi!
The same data also ends up in the bizarre $http_response_headers var
that gets spontaneously created in local scope - I've wondered about how
good that is to do.
This thing is indeed bizzare. I wonder if anybody uses it and why it was
done this way...
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
The same data also ends up in the bizarre $http_response_headers var
that gets spontaneously created in local scope - I've wondered about how
good that is to do.This thing is indeed bizzare. I wonder if anybody uses it and why it was
done this way...
I use this, mainly because I don't always have the file handle after calling
a function that does network requests. Who doesn't love a bit of 'magic' ;)
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
The same data also ends up in the bizarre $http_response_headers var
that gets spontaneously created in local scope - I've wondered about how
good that is to do.This thing is indeed bizzare. I wonder if anybody uses it and why it was done this way...
I've used it before... IIRC, it was because that var gets set on older PHP versions even if the HTTP response is an error (in which case the stream is destroyed and you can't get the metadata anymore either; newer versions have the "ignore_errors" context option for that).
David
Hi!
The same data also ends up in the bizarre $http_response_headers var
that gets spontaneously created in local scope - I've wondered about how
good that is to do.This thing is indeed bizzare. I wonder if anybody uses it and why it was done this way...
I've used it before... IIRC, it was because that var gets set on older PHP versions even if the HTTP response is an error (in which case the stream is destroyed and you can't get the metadata anymore either; newer versions have the "ignore_errors" context option for that).
I use it extensively. Its nearly the only way to get the headers from
file_get_contents() for example.
-Hannes
Hi!
I use it extensively. Its nearly the only way to get the headers from
file_get_contents()for example.
We could have a function, like stream_get_last_headers() or something
like that (like all DBs do, for example, which have exactly the same
issue with no handle on error). Injecting random variables in scope is
not usually the best way...
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
- Add a 'response_code' key, with the server response code as an integer
…
Anyone got any thoughts on this? I appreciate it'd be a BC break, but I think it might be useful.
While I applaud the idea of making this easier, keep in mind that a single request can have multiple status code responses:
<?php
$s = fopen('http://gimmebar.com/', 'r');
$m = stream_get_meta_data($s);
var_dump(array_filter($m['wrapper_data'], function ($l) {
if (substr($l, 0, 5) === 'HTTP/') {
return true;
}
}));
Outputs:
array(2) {
[0]=>
string(18) "HTTP/1.1 302 Found"
[8]=>
string(15) "HTTP/1.1 200 OK"
}
There could also be a large number of "HTTP/1.1 100 Continue" headers in there, or more 300 series redirects.
Putting the headers into an associative array also has similar problems (there can be many headers with the same name).
This can, of course, be worked around, but it's not as simple as just expecting a single response code from a HTTP stream request.
Aside, but related: most code I'd written prior to ~6 months ago, and most of the example code I've seen does something like:
list($prot, $status, $msg) = explode($m['wrapper_data'][0], 3);
…which is a nasty bug to track down.
S