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