[Python-ideas] PEP 3156: getting the socket or peer name from the transport

[Shane Green]

On Jan 27, 2013, at 8:28 AM, Guido van Rossum <guido at python.org> wrote:

> On Sun, Jan 27, 2013 at 4:16 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> Le dimanche 27 janvier 2013 à 14:12 +0200, Yuval Greenfield a écrit :
>>> On Sun, Jan 27, 2013 at 1:21 PM, Antoine Pitrou <solipsis at pitrou.net>
>>> wrote:
>>>> Most protocols should be written independent of transport.
>>>        But it seems to
>>>> me that a user might write an entire app as a "protocol".
>>> 
>>> 
>>>        Well, such an assumption can fall flat. For example,
>>>        certificate
>>>        checking in HTTPS expects that the transport is some version
>>>        of TLS or
>>>        SSL: http://tools.ietf.org/html/rfc2818.html#section-3.1
>>> 
>>> 
>>> I'm not sure I understood your reply. You'd be for an api that exposes
>>> the underlying transport? I meant to say that "an entire app" entails
>>> control over the subtleties of the underlying transport.
>> 
>> What I meant is that the HTTP protocol needs to know that it is running
>> over a secure transport, and it needs to fetch the server certificate
>> from that transport (or, alternatively, it needs to have one of its
>> callbacks called by the transport when the certificate is known). That's
>> not entirely transport-agnostic.
> 
> Yeah, it sounds like in the end having access to the socket itself (if
> there is one) may be necessary. I suppose there are a number of
> different ways to handle that specific use case, but it seems clear
> that we can't anticipate all use cases. I'd rather have a simpler
> abstraction with an escape hatch than attempting to codify more use
> cases into the abstraction. We can always iterate on the design after
> Python 3.4, if there's a useful generalization we didn't anticipate.
> 
> -- 
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas



What about giving the protocol an environ info object that should have all information it needs already, which could (and probably should) include things like the SSL certificate information, and would probably also be where additional info that happened to be looked up, like host name details, was stored and accessed.  Assuming the transports, etc., can define all the state information a protocol needs, can operate without hardware dependencies; in case that doesn't happen, though, the state dict will also have references to the socket, so the protocol could get to directly if needed. 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130128/8cf35984/attachment.html>