Allow context options when creating a socket

[elazar]

It's not currently possible to pass in context options (e.g. bindto) when creating a socket.

[cboden]

+1

[DaveRandom]

This is particularly important with the upcoming release of 5.6, which enables SSL peer verification by default. While #6 ensures this will work in the most cases (where the server certificate was issued by a trusted CA and the trusted CA list is correctly configured on the host system, *nix distros should do this and on Windows the system cert store will be used) there are common cases where there will still be issues.

Users must be able to supply custom CA file paths, as well as more advanced features such as thumbprints, or disabling verification (although this is strongly discouraged). It's also now possible - although currently undocumented - to specify the encryption type settings such as protocol and cipher lists) through the stream context, although currently this config would be overridden by the value passed to stream_socket_enable_crypto() by React, it would be good to prevent this happening if the user specifies their own config in context options.

I would suggest trying to find a general solution that can be applied to all streams - I still live in hope that SSL for React server sockets can be made to work in a sane way and they would be even more important there.

[clue]

👍 for adding context options!

But first, let's see which context options are relevant here (http://php.net/manual/en/context.php):

• socket has a single socket.bindto (http://php.net/manual/en/context.socket.php)
• ssl has quite a few ssl.* (http://php.net/manual/en/context.ssl.php)

The socket.bindto option could probably be exposed through a single scalar accessor, but the ssl.* options probably ask for an array of options anyway. Using an array has the benefit of automatically exposing any future context options. While it's very unlikely we'll see new relevant "context wrappers" here, it's very likely new "context options" will be introduced in the future.

Regarding the API, I'm not sure I like the suggestion of adding another $context (as in #17) like this: Connector::create($host, $port, $context). Let me quote from related ticket #10:

IMO we should first figure out some use cases for this feature to see how this is actually going to be used.

The socket-client component is quite lowlevel, so it's unlikely to be used by many users directly. It's probably more likely going to be used as part of some high level abstractions (say, a Redis or MySQL client implementation). These high level components depend on a ConnectorInterface and will likely use DI to inject this. They probably care little about how the connector works. Neither should they care about any "additional" parameters. They do care about the target (hostname and port).

As such, I don't think it makes much sense to ask your HTTP or MySQL client lib to pass in context options. As an alternative, I would suggest (somehow) assigning the context options to the connector instance itself. This makes for a more SOLID design and achieves a better separation of concerns.