Subject: [quicwg/base-drafts] Duplicate STREAM/CRYPTO_HS in the same packet (#1463)

From: Rui Paulo <[email-masked]>
Date: Tue, 19 Jun 2018 20:34:05 -0700

We should make it clear that implementations must handle overlapping data in all cases:

1) Duplicate STREAM/CRYPTO_HS in two different packets
2) Duplicate STREAM/CRYPTO_HS in the same packet
3) Duplicate STREAM/CRYPTO_HS in two packets but inside one UDP datagram

The receiver should discard overlapping data and not close the connection.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1463

---

From: MikkelFJ <[email-masked]>
Date: Tue, 19 Jun 2018 23:17:16 -0700

The order in which the receiver apply ranges and discards overlap is arbitrary and does not necessarily happen on any one frame boundary.

The sender SHOULD send the same content when introducing overlap (but can't always when relaying on external data sources).

The receiver MUST provide consistent view of data. Once a range is visible to the application it will not change.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1463#issuecomment-398636536

---

From: ekr <[email-masked]>
Date: Tue, 19 Jun 2018 23:32:25 -0700

This is not correct: https://tools.ietf.org/html/draft-ietf-quic-transport-12#section-9.5 says:

>  An endpoint could receive the same octets multiple times; octets that
   have already been received can be discarded.  The value for a given
   octet MUST NOT change if it is sent multiple times; an endpoint MAY
   treat receipt of a changed octet as a connection error of type
   PROTOCOL_VIOLATION.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1463#issuecomment-398639359

---

From: MikkelFJ <[email-masked]>
Date: Wed, 20 Jun 2018 00:30:37 -0700

Yes, sorry, I am aware that this is the case now. I propose to change it because it is impossible to conform to when using memory mapped files as a source on Linux.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1463#issuecomment-398652385

---

From: ekr <[email-masked]>
Date: Wed, 20 Jun 2018 00:32:02 -0700

Ah. I would oppose that change.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1463#issuecomment-398652718

---

From: Martin Thomson <[email-masked]>
Date: Wed, 20 Jun 2018 02:45:52 -0700

We discussed that specific possibility (that bytes can change after invoking sendfile() or equivalent), but I don't think that there was much appetite for allowing that.  See #1353.  If anyone disagrees with this, they are welcome to take that to the mailing list (or the chairs).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1463#issuecomment-398690343