Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Duplicate STREAM/CRYPTO_HS in the same packet #1463

Closed
rpaulo opened this issue Jun 20, 2018 · 7 comments
Closed

Duplicate STREAM/CRYPTO_HS in the same packet #1463

rpaulo opened this issue Jun 20, 2018 · 7 comments
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus.

Comments

@rpaulo
Copy link
Contributor

rpaulo commented Jun 20, 2018

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.

@mikkelfj
Copy link
Contributor

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.

@ekr
Copy link
Collaborator

ekr commented Jun 20, 2018

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

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.

@mikkelfj
Copy link
Contributor

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.

@ekr
Copy link
Collaborator

ekr commented Jun 20, 2018

Ah. I would oppose that change.

@martinthomson
Copy link
Member

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).

@martinthomson martinthomson added editorial An issue that does not affect the design of the protocol; does not require consensus. -transport labels Jun 26, 2018
@martinthomson
Copy link
Member

@rpaulo, looking at Section 9.5 and this issue, I'm not sure what more we could add. Is there something else we should be saying?

@rpaulo
Copy link
Contributor Author

rpaulo commented Sep 8, 2018

I had thought we could add a sentence about the different cases that data can be duplicated by an implementation but I think we can close.

@rpaulo rpaulo closed this as completed Sep 8, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus.
Projects
None yet
Development

No branches or pull requests

4 participants