quic: turn up status tests #15648
quic: turn up status tests #15648
Conversation
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
|
OK, all set, PTAL! |
| @@ -151,15 +151,21 @@ void EnvoyQuicClientStream::OnInitialHeadersComplete(bool fin, size_t frame_len, | |||
| return; | |||
| } | |||
| quic::QuicSpdyStream::OnInitialHeadersComplete(fin, frame_len, header_list); | |||
| ASSERT(headers_decompressed() && !header_list.empty()); | |||
There was a problem hiding this comment.
Does this really need to be moved down?
There was a problem hiding this comment.
Yep, the new 11111111...111 test fails that assertion.
There was a problem hiding this comment.
Does it fail because of header_list is empty? If so, there is nothing to validate at all. I think an early reset makes sense. TBH I don't know where could it fail in QUICHE stack, maybe Qpack decoding? Ideally, QUICHE should reset the stream in that case.
getResponseStatusNoThrow() uses absl::SimpleAtoi() which doesn't seem to check the status code to be a 3 digit code though. Did I miss something?
There was a problem hiding this comment.
yeah this is testing for overflow. Envoy allows greater than 3 digit but not overflowing is important.
| ASSERT_TRUE(fake_upstream_connection->write(std::string(overflowed_status))); | ||
| waitForNextUpstreamRequest(); | ||
| default_response_headers_.setStatus( | ||
| "11111111111111111111111111111111111111111111111111111111111111111"); |
There was a problem hiding this comment.
Does this invalid status code cause getResponseStatusNoThrow() to return nullopt to reset the stream?
I thought we will explicitly check status to be one of 1xx/2xx/3xx/4xx/5xx.
There was a problem hiding this comment.
That's exactly what happens. We're checking for 1xx below, but because we explicitly call QuicSpdyStream::OnInitialHeadersComplete rather than quic::QuicSpdyClientStream::OnInitialHeadersComplete we were missing at lease some quiche validation checks.
Alternately given we're failing the assert it's possible somewhere in the quiche stack also validated. Instead of resetting on Envoy's invalid status code we could instead reset on (!headers_decompressed() || header_list.empty()) in case there's other quiche validation checks we're failing?
There was a problem hiding this comment.
quic::QuicSpdyClientStream::OnInitialHeadersComplete() will copy and consume the headers and unblock the stream. Since we want headers to be decoded before decoding any data, skipping QuicSpdyClientStream::OnInitialHeadersComplete() is an easier implementation.
If the ASSERT() earlier-on fails, I suspect even QuicSpdyClientStream::OnInitialHeadersComplete() would fail because of empty headers instead of invalid status code.
There was a problem hiding this comment.
yeah, the assert fails for no status present. I can bump it back up for the test of "missing status header"
There was a problem hiding this comment.
SG. That means Envoy won't receive any overflow response status code from QUIC stream, is that correct?
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
|
@danzh2010 any other requests? |
| } | ||
|
|
||
| ASSERT_TRUE(fake_upstream_connection->waitForDisconnect()); |
There was a problem hiding this comment.
I suspect watiForDisconnect() here and above will be fixed by #15753. Mind adding a TODO here?
| ASSERT_TRUE(fake_upstream_connection->write(std::string(overflowed_status))); | ||
| waitForNextUpstreamRequest(); | ||
| default_response_headers_.setStatus( | ||
| "11111111111111111111111111111111111111111111111111111111111111111"); |
There was a problem hiding this comment.
SG. That means Envoy won't receive any overflow response status code from QUIC stream, is that correct?
|
@snowp dan has signed off for QUIC logic but can you do !Google/style pass? |
Tagging a bunch of quic test failures with more details.
Adapting the status code tests to QUIC and fixing QUIC code to validate.
minor refactors to core code.
Risk Level: low (minor core refactors)
Testing: new integration tests
Docs Changes: n/a
Release Notes: n/a
part of #14829