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

[Andrew Godwin]

On Thu, Mar 10, 2016 at 2:07 PM, Robert Collins 
wrote:

> On 11 March 2016 at 10:34, Andrew Godwin  wrote:
> >>
> >>
> >> I realise this may sound bikesheddy, but it would be really good to
> >> not call it ASGI. From your docs "
> >> Despite the name of the proposal, ASGI does not specify or design to
> >> any specific in-process async solution, such as asyncio, twisted, or
> >> gevent. Instead, the receive_many function can be switched between
> >> nonblocking or synchronous. This approach allows applications to
> >> choose what’s best for their current runtime environment; further
> >> improvements may provide extensions where cooperative versions of
> >> receive_many are provided."
> >>
> >> I'm worried that folk will assume a parallel between ASGI and asyncio,
> >> but there appears to be none... which is only a problem due to the
> >> room for confusion.
> >
> >
> > Better names are welcome, but I quite like ASGI's similarity to WSGI, and
> > the fact it's pronounceable as a single word. The "Asynchronous" part
> covers
> > the way the whole system operates; async is already an overloaded term,
> and
> > while there might be initial confusion, I think "async" also has strong
> > associations with the sort of problems ASGI solves (like websockets),
> which
> > I think is useful.
>
> Perhaps thats a particularly browser-centric view? There's nothing
> that strongly associates TCP with Python's slant on 'async' for me -
> interfaces on top of message passing can be sync or async - as in fact
> the switch you've got demonstrates :).
>
> Other names?
>
> quick thoughts...
> WSGP (web services gateway protocol)
> MuPGI (multiple protocol gateway interface)


Maybe, but this is specifically oriented as a web-based protocol - I'm not
proposing to replace all network processing here - and in that context,
"async" largely means "I can do things outside a normal request-response
process".

I guess it would take a lot for me to change the name at this point, as
it's already so many places, but I do see your point.


>
>
>
> >>  For consistency, why not a dict unicode -> List[bytes]
> >
> > I personally think this is worse than a list of tuples (which you can at
> > least feed straight into dict()) - the only header that comes through as
> > multiple, ever, is Set-Cookie, after all.
>
> I think you're wrong about that 'only header' statement.
>
> rfc 7230 3.2.2 permits multiple header fields with the same field name
> for all field values defined as comma separated lists, and for
> set-cookie.
>
> So  you can't feed it straight into dict, unless you place a
> requirement on the server to always fold together multiple header
> fields with the same field name and clients to not use that
> either. Oh, and special case Set-cookie.
>

I would indeed want to require servers to always fold headers together into
a comma-separated list, as that's what the RFC says, and it then means
applications only have to deal with one kind of multi-header!

Set-cookie is the annoying thing here, though. That's why it's dict inbound
and list of tuples outbound right now, and I just don't know if I want to
make the inbound one a list of tuples too, given I do definitely want to
force servers to concat headers together (unless I find any examples of
that screwing things up)

Andrew
___
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

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

[Robert Collins]

On 11 March 2016 at 10:34, Andrew Godwin  wrote:
>>
>>
>> I realise this may sound bikesheddy, but it would be really good to
>> not call it ASGI. From your docs "
>> Despite the name of the proposal, ASGI does not specify or design to
>> any specific in-process async solution, such as asyncio, twisted, or
>> gevent. Instead, the receive_many function can be switched between
>> nonblocking or synchronous. This approach allows applications to
>> choose what’s best for their current runtime environment; further
>> improvements may provide extensions where cooperative versions of
>> receive_many are provided."
>>
>> I'm worried that folk will assume a parallel between ASGI and asyncio,
>> but there appears to be none... which is only a problem due to the
>> room for confusion.
>
>
> Better names are welcome, but I quite like ASGI's similarity to WSGI, and
> the fact it's pronounceable as a single word. The "Asynchronous" part covers
> the way the whole system operates; async is already an overloaded term, and
> while there might be initial confusion, I think "async" also has strong
> associations with the sort of problems ASGI solves (like websockets), which
> I think is useful.

Perhaps thats a particularly browser-centric view? There's nothing
that strongly associates TCP with Python's slant on 'async' for me -
interfaces on top of message passing can be sync or async - as in fact
the switch you've got demonstrates :).

Other names?

quick thoughts...
WSGP (web services gateway protocol)
MuPGI (multiple protocol gateway interface)



>>  For consistency, why not a dict unicode -> List[bytes]
>
> I personally think this is worse than a list of tuples (which you can at
> least feed straight into dict()) - the only header that comes through as
> multiple, ever, is Set-Cookie, after all.

I think you're wrong about that 'only header' statement.

rfc 7230 3.2.2 permits multiple header fields with the same field name
for all field values defined as comma separated lists, and for
set-cookie.

So  you can't feed it straight into dict, unless you place a
requirement on the server to always fold together multiple header
fields with the same field name and clients to not use that
either. Oh, and special case Set-cookie.

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud
___
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

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

[Andrew Godwin]

>
>
>
> I realise this may sound bikesheddy, but it would be really good to
> not call it ASGI. From your docs "
> Despite the name of the proposal, ASGI does not specify or design to
> any specific in-process async solution, such as asyncio, twisted, or
> gevent. Instead, the receive_many function can be switched between
> nonblocking or synchronous. This approach allows applications to
> choose what’s best for their current runtime environment; further
> improvements may provide extensions where cooperative versions of
> receive_many are provided."
>
> I'm worried that folk will assume a parallel between ASGI and asyncio,
> but there appears to be none... which is only a problem due to the
> room for confusion.


Better names are welcome, but I quite like ASGI's similarity to WSGI, and
the fact it's pronounceable as a single word. The "Asynchronous" part
covers the way the whole system operates; async is already an overloaded
term, and while there might be initial confusion, I think "async" also has
strong associations with the sort of problems ASGI solves (like
websockets), which I think is useful.

>  For consistency, why not a dict unicode -> List[bytes]

I personally think this is worse than a list of tuples (which you can at
least feed straight into dict()) - the only header that comes through as
multiple, ever, is Set-Cookie, after all.

Andrew
___
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

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

[Robert Collins]

On 10 March 2016 at 13:34, Andrew Godwin  wrote:
> Hi all,
>
> As some of you may know, I've been working over the past few months to bring
> native WebSocket support to Django, via a project codenamed "Django
> Channels" - this is mostly the reason I've been involved in recent WSGI
> discussions.
>
> I'm personally of the opinion that WSGI works well for HTTP, with a few
> improvements we can roll into a 1.1, but that we also need something else
> that can support WebSockets and other future web protocols (e.g. WebRTC
> components).
>
> 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.


I realise this may sound bikesheddy, but it would be really good to
not call it ASGI. From your docs "
Despite the name of the proposal, ASGI does not specify or design to
any specific in-process async solution, such as asyncio, twisted, or
gevent. Instead, the receive_many function can be switched between
nonblocking or synchronous. This approach allows applications to
choose what’s best for their current runtime environment; further
improvements may provide extensions where cooperative versions of
receive_many are provided."

I'm worried that folk will assume a parallel between ASGI and asyncio,
but there appears to be none... which is only a problem due to the
room for confusion.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud
___
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

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

[Robert Collins]

On 11 March 2016 at 08:32, Andrew Godwin  wrote:
>
>
>
>
> Well, the protocol server would be the thing that's doing the joining if it
> sees multiple headers - you'd always see comma-joined headers from clients
> as an ASGI application, which I like as I like consistency.

For consistency, why not a dict unicode -> List[bytes]

?

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud
___
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

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

[Andrew Godwin]

On Thu, Mar 10, 2016 at 10:57 AM,  wrote:

> On Thu, 10 Mar 2016, Andrew Godwin wrote:
>
> 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.
>>
>
> It sounds like you consider multiple headers of the same name in
> request and response as some kind of bug or fault. It's not it is
> perfectly legit and something I want to be able to do in my webbby
> frameworks. Vary is the main one.
>
> I know that I can join on ',' in a single header when it is
> represented in a dict but "meh".
>

Well, the protocol server would be the thing that's doing the joining if it
sees multiple headers - you'd always see comma-joined headers from clients
as an ASGI application, which I like as I like consistency.


>
> I totally agree that dicts are much nicer to work with, so I'm not
> sure what the ideal solution is, but I just wanted to raise that
> point about multiple headers. As you were. Carry on. etc.


Yeah, I find the whole comma thing a bit weird, and sort of wonder if it's
actually a workable thing for all HTTP clients. I hope it is.

Andrew
___
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

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

[chris . dent]

On Thu, 10 Mar 2016, Andrew Godwin wrote:


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.


It sounds like you consider multiple headers of the same name in
request and response as some kind of bug or fault. It's not it is
perfectly legit and something I want to be able to do in my webbby
frameworks. Vary is the main one.

I know that I can join on ',' in a single header when it is
represented in a dict but "meh".

I totally agree that dicts are much nicer to work with, so I'm not
sure what the ideal solution is, but I just wanted to raise that
point about multiple headers. As you were. Carry on. etc.

--
Chris Dent   http://burningchrome.com/
[...]
___
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

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

[Andrew Godwin]

On Thu, Mar 10, 2016 at 1:59 AM, Cory Benfield  wrote:

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

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

[Ionel Maries Cristian]

Hey,

On Thu, Mar 10, 2016 at 2:34 AM, Andrew Godwin  wrote:

> Helpful quick Q: http://channels.readthedocs.org/en/latest/inshort.html
>

I have looked over that and it's not very clear what goes where. [1] I'd be
inclined to understand that the process type "that handles HTTP and
WebSockets" would be some sort of specialized proxy service that does the
websocket routing, proxying plain requests to the worker (for the regular
views) and specific frontend protocol handling (upgrading to
http2.0/websockets or whatever).
It would be more clear if the docs would include some diagrams illustrating
data flow and how all the components connect together with what protocols.

Shouldn't the process type "that handles HTTP and WebSockets" have a more
specific term? It's a bit long to type.

Spec is up here: http://channels.readthedocs.org/en/latest/asgi.html
>

Is ASGI a wire protocol? I'd assume it is, if multiple processes
communicate to each other with this protocol, but the docs don't have any
details about the exact wire format.

Also, some comparison to existing solutions (like Meteor/SockJS/Crossbar
/WAMP ) would help clearing
lots of questions.

​[1] Sorry if it sounds harsh, certainly not the intention. I'm just a bit
confused/overwhelmed.​

Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
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

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

[Cory Benfield]

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