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.

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

HTTP/3 codec does not set end_stream properly #28053

Open
jeongseokson opened this issue Jun 21, 2023 · 6 comments
Open

HTTP/3 codec does not set end_stream properly #28053

jeongseokson opened this issue Jun 21, 2023 · 6 comments
Labels
area/http area/quic bug no stalebot Disables stalebot from closing an issue

Comments

@jeongseokson
Copy link
Contributor

jeongseokson commented Jun 21, 2023

Title: HTTP/3 codec does not set end_stream properly

Description:
HTTP/3 codec does not set end_stream properly for decodeHeaders, and perhaps for other methods as well.
I think the issue is that OnInitialHeadersComplete of EnvoyQuicServerStream and EnvoyQuicClientStream just passes fin argument to decodeHeaders. However, the fin argument of OnInitialHeadersComplete doesn't seem to contain the right information based on the comments in the QUICHE code.

Repro steps:
I wrote an integration test using IntegrationCodecClient::startRequest, which internally calls encodeHeaders. I set the second header_only_request to true on the client side, and found that the fin argument of EnvoyQuicServerStream::OnInitialHeadersComplete is still set to false.

I think EnvoyQuicServerStream::OnInitialHeadersComplete should pass something different from the fin argument, perhaps fin_received() derived from QuicStream.

@jeongseokson jeongseokson added bug triage Issue requires triage labels Jun 21, 2023
@jeongseokson
Copy link
Contributor Author

Can you confirm whether this is a bug or not @danzh2010?

@danzh2010
Copy link
Contributor

danzh2010 commented Jun 21, 2023

In your test, did FIN arrive in OnBodyAvailable() with empty payload?

@jeongseokson
Copy link
Contributor Author

I have been working on something else now but I will check it soon and probably share the test through a PR soon so that you can take a look at it.

@kyessenov kyessenov removed the triage Issue requires triage label Jul 5, 2023
@github-actions
Copy link

github-actions bot commented Aug 4, 2023

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale stalebot believes this issue/PR has not been touched recently label Aug 4, 2023
@DavidSchinazi
Copy link
Contributor

@RyanTheOptimist could you add "no stalebot" tag to this issue please? (or let me know how I can do it myself if there's a way)

@RyanTheOptimist RyanTheOptimist added no stalebot Disables stalebot from closing an issue and removed stale stalebot believes this issue/PR has not been touched recently labels Aug 4, 2023
@RyanTheOptimist
Copy link
Contributor

Done!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/http area/quic bug no stalebot Disables stalebot from closing an issue
Projects
None yet
Development

No branches or pull requests

6 participants