Re: [PHP-DEV] Improvements to HTTP stream metadata

Hi!

On 6/30/11 2:34 PM, Michael Maclean wrote:
> 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

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Improvements to HTTP stream metadata

On Jul 1, 2011 7:31 AM, "Stas Malyshev" <smalyshev <at> sugarcrm.com> wrote:
>
> Hi!
>
>
> On 6/30/11 2:34 PM, Michael Maclean wrote:
>>
>> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] Improvements to HTTP stream metadata

> * 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. 

Re: [PHP-DEV] Re: Fix for #53727 (is_subclass_of resolution with interfaces)

Hi Ralph,

I reassigned it myself, and will take a look on Monday or Tuesday.

Thanks. Dmitry.

On 07/01/2011 02:48 AM, Ralph Schindler wrote:
> Hey Dmitry,
>
> is_a_impl() is an implementation that is shared by is_a() and
> is_subclass_of() calls. There is a flag called only_subclass that allows
> there to be switching behavior in is_a_impl().
>
> The issue has been updated with a new patch that now takes objects into
> account. It also has a comment in there that better explains what the
> patch is doing.
>
> I cannot assign it to you as I am not the original reporter, nor have
> access, can you assign it to yourself?
>
> Thanks,
> Ralph
>
> On 6/30/11 2:39 AM, Dmitry Stogov wrote:
>> Hi Ralph,
>>
>> I agree with expected behavior, but didn't understand the patch and
>> which side effects it may have as well as the original implementation of
>> is_a_impl(). It looks for me like one huge bug :)
>>

Re: [PHP-DEV] Improvements to HTTP stream metadata

On 01.07.2011, at 01:29, Stas Malyshev wrote:

> Hi!
> 
> On 6/30/11 2:34 PM, Michael Maclean wrote:
>> 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

Re: [PHP-DEV] Improvements to HTTP stream metadata

On Fri, Jul 1, 2011 at 10:18, David Zülke <david.zuelke <at> bitextender.com> wrote:
> On 01.07.2011, at 01:29, Stas Malyshev wrote:
>
>> Hi!
>>
>> On 6/30/11 2:34 PM, Michael Maclean wrote:
>>> 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

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Improvements to HTTP stream metadata

Hi!

On 7/1/11 3:08 AM, Hannes Magnusson wrote:
> 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

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Friendly log messages for CLI server

Hi,

There's now a request for this:
https://bugs.php.net/bug.php?id=55109

Colours are now toggled by the ini setting cli_server.color.

I'm still looking into means of excluding the more deceptively
incapable terminals but I will support having colours on by default
anyway.

Regards,

Arpad

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] remove FPM experimental flag on 5.4

Hi,

5.4 is coming is the next few months. FPM has been integrated into
5.3.3 and FPM is marked as experimental at configure.

I'd like to remove the FPM experimental flag in 5.4 and trunk. What do
you think ?

Maybe this needs a rfc/vote.

++ Jerome

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] remove FPM experimental flag on 5.4

On Sat, 2 Jul 2011, Jérôme Loyet wrote:

> 5.4 is coming is the next few months. FPM has been integrated into 
> 5.3.3 and FPM is marked as experimental at configure.
> 
> I'd like to remove the FPM experimental flag in 5.4 and trunk. What do 
> you think ?

Go for it!

Derick

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php