Hi Chris,
The fix ensures that any pending data frame will still be processed
after 204 has been received - thus triggering the logic that
eventually closes the stream.
I suppose that a 204 response MUST have an END_STREAM
in its final HEADERS / CONTINUATION frame, right?
I have rescanned the RFC. I could not find a definitive answer to
that question. AFAIU it's expected that the HEADERS frame will
carry the END_STREAM - but there is some sibylline text that let
me think that having an empty DATA frame carrying the END_STREAM
would be OK too:
<<< A response
that is defined to have no payload, as described in [RFC7230],
Section 3.3.2, can have a non-zero content-length header field, even
though no content is included in DATA frames. >>>
It is allowable for a HEADERS frame to carry an END_STREAM,
but not an END_HEADERS. If this happens, then CONTINUATION
frames must follow, the last of which will carry END_HEADERS.
That probably explains why the END_STREAM handling is done
the way that it is.
Yes. And the CONTINUATION frame is not supposed to carry the
END_STREAM - so we can see END_STREAM before END_HEADERS.
Therefore I have removed my changes to HeaderFrame.java.
Code inspection shows that we might not deal with that situation
properly - so I have logged https://bugs.openjdk.java.net/browse/JDK-8242999
to follow up on this.
The new test is good, but has an unnecessary reference to
AbstractThrowingSubscribers.TestExecutor.
https://bugs.openjdk.java.net/browse/JDK-8238270
Done.
New webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8238270/webrev.01/
best regards, and thanks for the valuable feedback!
-- daniel
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8238270/webrev.00/index.html
