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

[Umbrella Code]

It's been a few years so my memory must be rusty, but where is the https protocol dependent on the transport/SSL setup in that way?

Sent from my iPad

Begin forwarded message:

> From: Umbrella Code <shane at umbrellacode.com>
> Date: January 27, 2013, 9:06:48 AM PST
> To: Guido van Rossum <guido at python.org>
> Subject: Re: [Python-ideas] PEP 3156: getting the socket or peer name from the transport
> 
> It's been a few years so my memory must be rusty, but where is the https protocol dependent on the transport/SSL setup in that way?
> 
> 
> Sent from my iPad
> 
> 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 thsay 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130127/93013124/attachment.html>