-
Notifications
You must be signed in to change notification settings - Fork 204
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
Comments
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. |
This is not correct: https://tools.ietf.org/html/draft-ietf-quic-transport-12#section-9.5 says:
|
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. |
Ah. I would oppose that change. |
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). |
@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? |
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. |
We should make it clear that implementations must handle overlapping data in all cases:
The receiver should discard overlapping data and not close the connection.
The text was updated successfully, but these errors were encountered: