> On 10 Mar 2016, at 00:34, Andrew Godwin <and...@aeracode.org> wrote: > > To that end, I did some work to make the underlying mechanism Django Channels > uses into more of a standard, which I have codenamed ASGI; while initially I > intended for it to be a Django documented API, as I've gone further with the > project I've come to believe it could be useful to the Python community at > large. >
Andrew, Thanks for this work! I’ve provided some proposed changes as pull requests against the channels repository. I’ll ignore those for the rest of the email: we can discuss them on GitHub. I also have a few more general notes. I didn’t make PRs for these, mostly because they’re too “vague” as feedback goes to be concretely handled by me. First, your HTTP section has request headers serialized to a dict and response headers serialized to a list of tuples. I’m not sure how I feel about that asymmetry: it might be cleaner just to use lists-of-tuples in both places and allow application frameworks to handle translation to dictionary if they require it. Second, if it were me I’d remove the `status_text` field on the `Response` object. Custom status text is a terrible misfeature (especially as HTTP/2 doesn’t support it), and in 99% of cases you’re just wasting data by repeatedly sending the default phrase that the server already knows. Third, you’re currently sending header fields with unicode names and byte string values. That’s understandable, but I wonder if it’s worthwhile trying to limit the behaviour of compliant servers in encoding/decoding those header fields. For example, you could assert that the unicode header names will always use the Latin-1 codec when encoding/decoding. This is mostly me being paranoid about poorly written apps/servers issuing bad bytes onto the network. I should note that RFC 7230 strictly limits header names to US-ASCII, but Latin-1 would be the defensive choice against already-badly-written apps. Your section on server push is great, whoever wrote that is clearly a genius. ;) You define web socket data frames with an incrementing counter from zero, but also note that the maximum integer size is Python’s sys.maxint (you actually aren’t that clear about it, which might be a good idea). While this is *probably* not a problem, you may want to note that really long running or active web socket connections are at risk of exhausting the ‘order’ counter, and define a behaviour if that happens. Otherwise, this is an interesting specification. I’m certainly open to helping push it through the PEP process if you’d like assistance with that. Cory
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
