On Sun, Jan 22, 2017 at 4:01 AM, Cory Benfield <cory@lukasa.co.uk> wrote:
On 20 Jan 2017, at 23:00, Nathaniel Smith <njs@pobox.com> wrote:
- given that for next protocol negotiation we have to accept arbitrary bytestrings and the primary value of the NextProtocol class is to protect against typos, I wonder if it would simplify things slightly to make the attributes of this class just *be* bytestrings. I.e. what you have now but without the inheritance from enum.
While we *could*, I don’t think the value-add of doing this is very high. Basically the only thing it simplifies is the type declaration, and I don’t know that it’s worth doing that. ;)
Well, and the code that receives the values, which currently has to handle both enums and bytestrings. Agreed it's not a big deal, it just seems like the value the enum is adding is all negative.
- what object types *do* you expect to be passed to wrap_buffers? I was assuming bytearrays, but the text at the bottom suggests file-likes?
Yeah, good question. I was assuming file-likes as well, but I don’t see any reason we couldn’t also do bytearrays. What do you think the advantage of that is?
I've just been used to using bytearrays everywhere for things like socket receive buffers. I find them much more convenient to work with than BytesIO b/c you can do things like pass them directly to send/recv/parsing functions, and they have nice properties like O(1) deletion from the front. It doesn't matter so much for this case where we're just shuffling bytes to and from a socket in a lump, but that's why I was assuming bytearrays without thinking about it :-). I guess h2's data_to_send and data_received don't involve any file-like objects either?
It isn't quite clear to me right now how this kind of API should look with your proposal. Obviously they can't just take a SSLConfiguration object, because there's no way to look at an SSLConfiguration object and figure out what backend is in use (even though in general a given SSLConfiguration is only usable with a specific backend, because backends provide the Cert type etc). They could take a ServerContext/ClientContext, I guess? But it would be nice if there were some way to say "give me the default configuration, using SChannel". Or to write a function that sets up an SSLConfiguration while being generic over backends, so like it takes the backend as an argument and then uses that backend's cert type etc.
Yeah, I was assuming that they’d take a ClientContext/ServerContext object, rather than a configuration plus an instruction on which backend to use. It’s not clear to me that a function that setups up a configuration while generic over backends is actually a meaningful thing to have: are there really going to be users who are insistent on a specific TLS configuration but don’t care what concrete implementation is going to be used, such that their libraries have to pick it for them?
I think it's more likely the other way around -- users need to override the default backend, but don't want to specify all the details? And any library that does build configuration should be able to do it using generic code so long as it's sticking to generic features? requests.get(..., backend=WeirdEmbeddedTLSLib) -> "I need to use this lib, but requests should pick the ciphers/TLS version/etc., I'll just screw it up" web-server.cfg: listen-port = 443 [ssl] enabled = True backend = SChannel certificate = foo.pem Like, in the PEP as currently written, it goes to great efforts to make sure that generic code can be used to select cipher suites, but there's no way for a web server to load in certificate given a PEM filename, except via having a hard-coded table of all possible backends? The PEP says that each backend should somehow somewhere provide a concrete subclass of Certificate, but to find it you need to consult the backend-specific docs. This is really a usability point that's mostly orthogonal to the semantics/design discussion and should be pretty straightforward to sort out, so it might make sense to defer worrying about it until the other stuff's more settled. -n -- Nathaniel J. Smith -- https://vorpus.org