Posted by Jochem Maas on 01/20/06 15:10

I think you need to create a stream context resource with:

http://www.php.net/manual/en/function.stream-context-create.php

set the options you need on it with:
http://www.php.net/manual/en/function.stream-context-set-option.php

then pass the resource as the 4th arg to fopen() (rather passing in an array)


....i think

Richard Lynch wrote:
> On Thu, January 19, 2006 4:08 pm, Geoff wrote:
>
>>I honestly have no idea if this would work, but maybe fopen supports
>>non-blocking connections?
>
>
> Not as far as I can tell...
>
> You can call stream_set_blocking after it's open, but that doesn't
> help a slow connection in the first place.
>
>
>>Or creation of context-based connections
>>(for which you can use stream_set_blocking).
>
>
> Unless I'm seriously mis-reading docs, stream_set_blocking can only be
> called on an already-open stream, not on the soon-to-be-opened stream.
>
> fopen() in PHP5 does take a context, and if I could figure out how to
> embed the concepts of "do not block" and "timeout in $x seconds"
> within a context from the docs, and if fopen() would still handle all
> the details of the various protocols, I'd be all set...
>
> That's sort of what I was asking for in the original email, but...
>
> It seems like you have to specify the 'scheme' as the key in the
> context array.
>
> So, I guess, I could, in theory, find a listing of all the schemes
> fopen() supports, which might even be in a function, iterate over all
> of those, and do something like:
> $schemes = function_that_returns_all_schemes_fopen_supports();
> $opts = array();
> foreach($schemes as $scheme){
> $opts[$scheme]['some_magic_undocumented_thing'] =
> STREAM_CLIENT_ASYNC_CONNECT | STREAM_CLIENT_CONNECT ;
> }
>
> $foo = fopen($url, 'r', false, $opts);
> if ($foo == false) $errors[] = "$url timed out";
>
> Only problem is, these constants are documented ONLY to work with:
> http://www.php.net/manual/en/function.stream-socket-client.php
> and that pretty clearly is working at a much lower-level than fopen
> (and friends) as the very first example shows using TCP as a protocol,
> and then you have to send the GET and any other headers, which is
> exactly what I'm trying to avoid having to re-code in the first place.
>
> So I'm back to square one, as far as I can see from the docs...
>
> It's possible (still) that I'm just mis-reading docs, or am
> continually skipping over the one new page in 'streams' that is making
> everybody think this should be so simple, but I don't think so, since
> I've read EVERY page in the new streams section several times now.
>
> I'm not claiming 100% comprehension of every implication on every
> page, mind you :-)
>
>
>>If so, you could take a
>>stamp of the current time plus a timeout value, make the fopen call
>>(which would return immediately) then wait politely (I mean that
>>from a CPU perspective) in a loop until you have data, or the
>>current time goes past your time stamp.
>
>
> Yes -- if I could compose a stream_context doohickey that convinced
> fopen() to use a time-out...
>
>
>>Another avenue for investigation might be to try file_get_contents
>>to see if it's connection timeout can be controlled. It seems to
>>work in a similar way to fopen, in terms of having wrappers that are
>>aware of multiple resource types.
>
>
> file_get_contents() seems to suffer from the exact same limitations of
> file()
>
> I get the simplicity of fopen() with no control over connection timeout.
>
> Maybe there is some underlying voodoo going on in the PHP internals
> that some makes it crystal-clear why that has to be, but to this naive
> user, if fsockopen can have a timeout, fopen and friends out to be
> able to also, at least for schemes that support such a thing.
>
> Obviously SOME kind of timeout is involved somewhere in fopen()
> because it WILL timeout on some sites sometimes, even though
> experimentation has shown that had it waited, it would have gotten
> data eventually.
>
>
>>It might also be worth taking a look at cURL or similar libraries
>>that are also multi-resource aware, but give you greater control of
>>connections parameters and timeouts.
>
>
> Maybe I've been mis-using cURL all these years, but it doesn't seem to
> be anywhere near as simple as the mythical function I've described,
> and really not much better than a giant switch for fsockopen to
> duplicate all that code that's gotta be down in the guts of fopen (and
> friends)
>

[Back to original message]