Alan Kennedy wrote:
> [Brian]
> > Here is the change that removes the use of RFC 2047 from HTTP in
> HTTPbis.
>
> Grand so; all we need to do is to wait for everyone to stop using
> HTTP/1.1, start using HTTP/bis, and our problems are at an end!
HTTPbis *is* (will be) HTTP/1.1. It doesn't define
[Brian]
> Here is the change that removes the use of RFC 2047 from HTTP in HTTPbis.
Grand so; all we need to do is to wait for everyone to stop using
HTTP/1.1, start using HTTP/bis, and our problems are at an end!
;-)
Alan.
___
Web-SIG mailing list
Web
[James]
> If you want to start a discussion about having a standard parsed-header
> object in WSGI, that's another thing, but saying that WSGI servers should
> *partially* decode the headers seems rather silly to me.
Hi James,
It's a shame that your proposal to add the twisted header parsing
libr
On Wed, Apr 8, 2009 at 1:14 PM, James Y Knight wrote:
> If you want to start a discussion about having a standard parsed-header
> object in WSGI, that's another thing,
Off topic to this discussion, but that's what WebOb is. It also largely
handles the encoding issues, abstracts away the awkwar
Robert Brewer wrote:
> Brian Smith wrote:
> > Here is the change that removes the use of RFC 2047 from HTTP in
> > HTTPbis.
>
> Yes, but parsers need to continue decoding them for many years to come.
> IMO WSGI origin servers should do this so we can write the decoding
> logic once and forget ab
On Apr 8, 2009, at 12:57 PM, Robert Brewer wrote:
Yes, but parsers need to continue decoding them for many years to
come.
IMO WSGI origin servers should do this so we can write the decoding
logic once and forget about it (assuming middleware and apps far
outnumber origin servers).
Decoding RF
Brian Smith wrote:
> Here is the change that removes the use of RFC 2047 from HTTP in
> HTTPbis.
Yes, but parsers need to continue decoding them for many years to come.
IMO WSGI origin servers should do this so we can write the decoding
logic once and forget about it (assuming middleware and apps
