[Web-SIG] Inviting feedback on my proposed "ASGI" spec

[Andrew Godwin]

On Thu, Mar 10, 2016 at 1:59 AM, Cory Benfield <cory at lukasa.co.uk> wrote:

>
> > On 10 Mar 2016, at 00:34, Andrew Godwin <andrew at 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.
>

I think you're right, and I've just been stubbornly trying to use a dict as
it's slightly "nicer". I honestly considered making both sides dict and
cookies the separate thing as they're the only special case, but I suspect
that multiple headers are one of those things that might turn out to be
useful for some broken client/new feature someday.


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

Well, it IS optional; you only need to send it if you're changing it from
the default or providing an unusual new value (e.g. 418). We could change
the spec to say servers don't have to abide by it, too. I have done a
project in the past with custom reason phrases, that's all :)


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

Yes, it's perhaps an unwritten understanding that they're meant to be
encoded/decoded only to latin1, and I believe this is what Daphne does;
they're unicode mostly as that makes keying into the header dictionary much
nicer in py3/unicode_literals land, and because there's a clear encoding
way to handle them.


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

Ah, good catch. I'll specify a very high maximum order number for any
protocol and say it rolls over to 0 for the next one, and then I can modify
channels' global_ordering to expect that - I think that's the most sensible
approach here.


>
> 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.
>
>
If we see some rough agreement on it, yes, I would love some help with that.

Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20160310/b0de0029/attachment.html>