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.

Sign up for GitHub

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

Jump to bottom

closed streams #145

Closed
wants to merge 4 commits into from
Closed

closed streams #145

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
1c08483
handle reordered RST_STREAM frames and FIN flags
marten-seemann Jan 13, 2017
782263a
allow reading from streams that a RST_STREAM has been received for
marten-seemann Jan 13, 2017
70bf032
Revert "allow reading from streams that a RST_STREAM has been receive…
marten-seemann Jan 16, 2017
080506c
minor changes, fix typos
marten-seemann Jan 16, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
29 changes: 16 additions & 13 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -1473,27 +1473,30 @@ contains a FIN flag or when either peer sends a RST_STREAM frame.

The "closed" state is the terminal state.

A final offset is present in both a frame bearing a FIN flag and in a RST_STREAM
frame. Upon sending either of these frames for a stream, the endpoint MUST NOT
send a STREAM frame carrying data beyond the final offset.
A final offset is present in both a STREAM frame bearing a FIN flag and in a
RST_STREAM frame. Upon sending either of these frames for a stream, the
endpoint MUST NOT send a STREAM frame carrying data beyond the final offset.

An endpoint that receives any frame for this stream after receiving either a FIN
flag and all stream data preceding it, or a RST_STREAM frame, MUST quietly
discard the frame, with one exception. If a STREAM frame carrying data beyond
the received final offset is received, the endpoint MUST close the connection
with a QUIC_STREAM_DATA_AFTER_TERMINATION error ({{error-handling}}).
An endpoint that receives a FIN flag or a RST_STREAM frame knows the final
offset for this stream. If a STREAM frame carrying data beyond the received
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally (and YMMV) I find the new wording here a bit confusing, and I'd keep the previous one for this case (with your addition in the next paragraph).

final offset is received, the endpoint MUST close the connection with a
QUIC_STREAM_DATA_AFTER_TERMINATION error ({{error-handling}}).

An endpoint MUST close the connection with a QUIC_STREAM_DATA_AFTER_TERMINATION
error if it receives a RST_STREAM frame or a FIN flag with a lower final offset
than the highest data offset it already received on that stream.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be simplified greatly:

If a STREAM frame carries data with an offset higher than the final offset, {{ERROR}}. If a RST_STREAM or a STREAM frame marked with a FIN flag indicates a different final offset, {{ERROR}}.


An endpoint that receives a RST_STREAM frame (and which has not sent a FIN or a
RST_STREAM) MUST immediately respond with a RST_STREAM frame, and MUST NOT send
any more data on the stream. This endpoint may continue receiving frames for
the stream on which a RST_STREAM is received.

If this state is reached as a result of sending a RST_STREAM frame, the peer
that receives the RST_STREAM might have already sent -- or enqueued for sending
-- frames on the stream that cannot be withdrawn. An endpoint MUST ignore
frames that it receives on closed streams after it has sent a RST_STREAM frame.
An endpoint MAY choose to limit the period over which it ignores frames and
treat frames that arrive after this time as being in error.
that receives the RST_STREAM frame might have already sent -- or enqueued for
sending -- frames on the stream that cannot be withdrawn. An endpoint MUST
ignore frames that it receives on closed streams after it has sent a RST_STREAM
frame. An endpoint MAY choose to limit the period over which it ignores frames
and treat frames that arrive after this time as being in error.

STREAM frames received after sending RST_STREAM are counted toward the
connection and stream flow-control windows. Even though these frames might be
Expand Down