Yes, I thought that was the case. I think adding lowercase normalisation to
header names to the spec would be sensible (daphne already does this, but
I'd like to make it reliable upon)
Andrew
On Fri, Mar 11, 2016 at 10:03 AM, Collin Anderson
wrote:
> http2 makes all header names lowercase
>
> O
http2 makes all header names lowercase
On Fri, Mar 11, 2016 at 12:59 PM, Andrew Godwin wrote:
> One thing I did want to ask - is it worth still squashing everything down
> to the same case? Daphne already clears out headers with _ in them to avoid
> that CVE about it, and header case is never se
One thing I did want to ask - is it worth still squashing everything down
to the same case? Daphne already clears out headers with _ in them to avoid
that CVE about it, and header case is never semantic, or so I thought?
Andrew
On Fri, Mar 11, 2016 at 9:56 AM, Andrew Godwin wrote:
>
>
> On Fri,
On Fri, Mar 11, 2016 at 2:28 AM, Cory Benfield wrote:
>
> On 10 Mar 2016, at 23:56, Andrew Godwin wrote:
>
> 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
Just a thought from a non-wsgi developer: I think it might be smart to
follow http2 when in doubt on a question:
- http2 preserves header order and allows duplicates in both directions. A
list of tuples seems to be the best data structure IMHO.
- http2 ignores reason phrases, which makes me think
> On 10 Mar 2016, at 23:56, Andrew Godwin wrote:
>
> 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!
Well….kinda?
The RFC s
> On 10 Mar 2016, at 18:36, Andrew Godwin wrote:
>
>
> 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 se
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 desi
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, twi
>
>
>
> 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
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.
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
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
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 o
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
Hey,
On Thu, Mar 10, 2016 at 2:34 AM, Andrew Godwin wrote:
> Helpful quick Q&A: 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" wo
> 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
> pr
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
18 matches
Mail list logo
