[Python-Dev] Accepting PEP 3154 for 3.4?
Guido van Rossum
guido at python.org
Wed Nov 20 17:07:15 CET 2013
A problem with chunked IIRC is that the frame headers are variable-length
(a CRLF followed by a hex number followed by some optional gunk followed by
CRLF) so you have to drop back into one-byte-at-a-time to read it. (Well, I
suppose you could read 5 bytes, which is the minimum: CR, LF, X, CR, LF,
and when the second CR isn't among these, you have a lower bound for how
much more to read, although at that point you better load up on coffee
before writing the rest of the code. :-)
Some good things about it:
- Explicit final frame (byte count zero), so no need to rely on the data to
know the end.
- The redundancy in the format (start and end with CRLF, hex numbers) makes
it more likely that framing errors (e.g. due to an incorrect counting or
some layer collapsing CRLF into LF) are detected.
On Wed, Nov 20, 2013 at 7:44 AM, "Martin v. Löwis" <martin at v.loewis.de>wrote:
> Am 20.11.13 06:18, schrieb Tim Peters:
> > BTW, I'm not a web guy: in what way is HTTP chunked transfer mode
> > viewed as being flawed? Everything I ever read about it seemed to
> > think it was A Good Idea.
> It just didn't work for some time, see e.g.
> It's not that the protocol was underspecified - just the implementation
> was "brittle" (if I understand that word correctly). And I believe (and
> agree with you) that the cause for this "difficult to implement"
> property is that the framing is in putting framing "in the middle"
> of the stack (i.e. not really *below* pickle itself, but into pickle
> but below the opcodes - just like http chunked transfer is "in" http,
> but below the content encoding).
> Python-Dev mailing list
> Python-Dev at python.org
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev