- From: Mark Nottingham <mnot@mnot.net>
- Date: Sun, 20 Jul 2014 15:52:17 -0400
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>
<https://github.com/http2/http2-spec/issues/555> Anyone with thoughts on this? On 12 Jul 2014, at 4:30 am, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > Another issue I don't want to raise in the current melee, but I > think we should take it as an isssue, discuss it and close it, > so we can claim that we thought about it: > > > Has anybody considered frame-desynchronization ? > > The framing layer has neither pattern, checksum or sequence numbers > to help us tell if the sender and receiver have become mis-synchronized, > > If we wanted to be strictly compliant with "end-to-end argument" we > should have an integrity check, but given that we have a CRC and > sums in the layers below I don't think that's really an overhead > which would justify itself. > > However, it would make good sense to add a pattern or sequence > number to the frame header to give us a "must match field" to detect > frame misalignment. (I looked at the current frames and there > are no fields which lend themselves naturally to this). > > If a frame header gets misaligned one byte either way, there are > pretty good chances that it will still look legit enough for > processing to commence. > > Given that many people talk about processing frames while they are > still being received, adding a more robust misalignment detection > sounds like a good idea to me. > > The easiest is probably a single byte sequence number which just > increments from frame to frame. That number could be included > in RST frames to indicate which frame caused the error. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. -- Mark Nottingham http://www.mnot.net/
Received on Sunday, 20 July 2014 19:52:41 UTC