> 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.


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.


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Web-SIG mailing list
Web SIG: http://www.python.org/sigs/web-sig

Reply via email to