- From: Michael Sweet <msweet@apple.com>
- Date: Mon, 21 Jul 2014 09:27:34 -0400
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>
Generally I think this is unnecessary - HTTP depends on "reliable" transport (TCP as defined) so we probably don't need this for frames generally. It could be useful for HEADERS/PUSH_PROMISE for tracking which version of the header table is in use (see my recent posting on the Cost Analysis thread), but that all depends on how hard we want to avoid dropping connections when things go wrong... On Jul 20, 2014, at 3:52 PM, Mark Nottingham <mnot@mnot.net> wrote: > <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/ > > > > _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair
Received on Monday, 21 July 2014 13:28:11 UTC