You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "yinwoods (Jira)" <ji...@apache.org> on 2021/11/09 01:47:00 UTC
[jira] [Comment Edited] (HTTPCORE-696) When H2 connection turns to
be graceful shutdown, a single HEADERS or PUSH_PROMISE frame with the
END_HEADERS flag set should be consumed
[ https://issues.apache.org/jira/browse/HTTPCORE-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17440846#comment-17440846 ]
yinwoods edited comment on HTTPCORE-696 at 11/9/21, 1:46 AM:
-------------------------------------------------------------
In Section 6.8 [https://datatracker.ietf.org/doc/html/rfc7540#section-6.8,]
{quote}After sending a GOAWAY frame, the sender can discard frames for
streams initiated by the receiver with identifiers higher than the
identified last stream. However, any frames that alter connection
state cannot be completely ignored. For instance, HEADERS,
PUSH_PROMISE, and CONTINUATION frames MUST be minimally processed to
ensure the state maintained for header compression is consistent (see [Section 4.3|https://datatracker.ietf.org/doc/html/rfc7540#section-4.3]
);
similarly, DATA frames MUST be counted toward the
connection flow-control window. Failure to process these frames can
cause flow control or header compression state to become
unsynchronized.
{quote}
and in Section 4.3,
{quote}A receiving endpoint reassembles the header block by concatenating
its fragments and then decompresses the block to reconstruct the
header list.
A complete header block consists of either:
o a single HEADERS or PUSH_PROMISE frame, with the END_HEADERS flag
set, or
o a HEADERS or PUSH_PROMISE frame with the END_HEADERS flag cleared
and one or more CONTINUATION frames, where the last CONTINUATION
frame has the END_HEADERS flag set.
Header compression is stateful. One compression context and one
decompression context are used for the entire connection. A decoding
error in a header block MUST be treated as a connection error
([Section 5.4.1|https://datatracker.ietf.org/doc/html/rfc7540#section-5.4.1]
) of type COMPRESSION_ERROR.
{quote}
I'm not sure about how to deal with a single HEADERS with the END_HEADERS flag set. Thanks [~olegk]
was (Author: yinwoods):
In Section 6.8 [https://datatracker.ietf.org/doc/html/rfc7540#section-6.8,]
{quote}After sending a GOAWAY frame, the sender can discard frames for
streams initiated by the receiver with identifiers higher than the
identified last stream. However, any frames that alter connection
state cannot be completely ignored. For instance, HEADERS,
PUSH_PROMISE, and CONTINUATION frames MUST be minimally processed to
ensure the state maintained for header compression is consistent (see [Section 4.3|https://datatracker.ietf.org/doc/html/rfc7540#section-4.3]
);
similarly, DATA frames MUST be counted toward the
connection flow-control window. Failure to process these frames can
cause flow control or header compression state to become
unsynchronized.
{quote}
and in Section 4.3,
{quote} A receiving endpoint reassembles the header block by concatenating
its fragments and then decompresses the block to reconstruct the
header list.
A complete header block consists of either:
o a single HEADERS or PUSH_PROMISE frame, with the END_HEADERS flag
set, or
o a HEADERS or PUSH_PROMISE frame with the END_HEADERS flag cleared
and one or more CONTINUATION frames, where the last CONTINUATION
frame has the END_HEADERS flag set.
Header compression is stateful. One compression context and one
decompression context are used for the entire connection. A decoding
error in a header block MUST be treated as a connection error
([Section 5.4.1|https://datatracker.ietf.org/doc/html/rfc7540#section-5.4.1]
) of type COMPRESSION_ERROR.{quote}
I'm not sure about how to deal with a single HEADERS with the END_HEADERS flag set. Thanks
> When H2 connection turns to be graceful shutdown, a single HEADERS or PUSH_PROMISE frame with the END_HEADERS flag set should be consumed
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HTTPCORE-696
> URL: https://issues.apache.org/jira/browse/HTTPCORE-696
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore
> Affects Versions: 5.1
> Reporter: yinwoods
> Priority: Major
> Attachments: image-2021-11-08-20-06-43-301.png, image-2021-11-08-20-07-02-610.png
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> current implemention in version 5.1, when connection gracefully shutdown and receives a single HEADERS frame with END_HEADERS flag set, it will throws "Stream refused" exception, not sure about this.
> As RFC7540 section 4.3 defines, looks like single HEADERS frame should be consumed.
>
> This code in org/apache/hc/core5/http2/impl/nio/AbstractH2StreamMultiplexer.java:1073
>
> !image-2021-11-08-20-07-02-610.png!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org