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 error against www.google.com #7625

Closed
yschimke opened this issue Feb 20, 2022 · 7 comments · Fixed by #7637
Closed

HTTP/3 error against www.google.com #7625

yschimke opened this issue Feb 20, 2022 · 7 comments · Fixed by #7637
Assignees
Labels
Bug For general bugs on Jetty side

Comments

@yschimke
Copy link

Jetty version(s)

11.0.8

Java version/vendor (use: java -version)

openjdk version "11.0.14.1" 2022-02-08 LTS
OpenJDK Runtime Environment Zulu11.54+25-CA (build 11.0.14.1+1-LTS)
OpenJDK 64-Bit Server VM Zulu11.54+25-CA (build 11.0.14.1+1-LTS, mixed mode)

OS type/version

OSX - M1

Description

Connecting to www.google.com/142.250.178.4:443
onPreface HTTP3SessionClient@641dca0b[streams=0,CLOSED]
onDisconnect 265 settings_reserved java.lang.IllegalArgumentException: invalid reserved setting
onDisconnect 265 settings_reserved

How to reproduce?

Works

"https://www.cloudflare.com:443/robots.txt"

Fails

https://www.google.com:443/robots.txt

I'm using a client code pretty much just from https://www.eclipse.org/jetty/documentation/jetty-11/programming-guide/index.html#pg-client-http3

@yschimke yschimke added the Bug For general bugs on Jetty side label Feb 20, 2022
@yschimke
Copy link
Author

I can provide a full example if requested, but it's in a larger code base.

@lorban
Copy link
Contributor

lorban commented Feb 21, 2022

There seems to be a bug in our HTTP3 Settings frame parser as it rejects key 1 with a new IllegalArgumentException("invalid reserved setting") while the latest draft 34 states that it is valid: https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-34#section-11.2.2

We'll get this fixed, thank you for your report!

@lorban
Copy link
Contributor

lorban commented Feb 21, 2022

@sbordet do we both read the H3 spec the same way?

@sbordet
Copy link
Contributor

sbordet commented Feb 21, 2022

@lorban @yschimke I read from the HTTP/3 specification (here):

Setting identifiers which were defined in [HTTP2] where there is no
corresponding HTTP/3 setting have also been reserved
(Section 11.2.2). These reserved settings MUST NOT be sent, and
their receipt MUST be treated as a connection error of type
H3_SETTINGS_ERROR.

Settings 0x06 overlaps, but in HTTP/3 there is no trace of 0x01.
Ah, it's because it's overridden by QPACK here.
Genius 😒

@sbordet
Copy link
Contributor

sbordet commented Feb 21, 2022

@lachlan-roberts so it is possible that a HTTP/3 SETTINGS is received with settings 0x01 and 0x07 (see https://datatracker.ietf.org/doc/html/draft-ietf-quic-qpack-21#section-5).

We currently do nothing upon receiving these QPACK settings.
Are there setters that I can call in the Qpack[Encoder|Decoder] APIs that will cause these settings to be effective?

@sbordet
Copy link
Contributor

sbordet commented Feb 21, 2022

I can confirm that not rejecting setting 0x01 results in a successful request/response from google.com.

Waiting on @lachlan-roberts for APIs details.
Currently maxBlockedStreams is a final field in QpackEncoder -- does it need to send instructions to the other peer if we make it mutable (like QpackEncoder.setCapacity() does)?

@lachlan-roberts
Copy link
Contributor

@sbordet for SETTINGS_QPACK_MAX_TABLE_CAPACITY (0x1) you should call Encoder.setCapacity(), this will send the capacity instruction to the remote Decoder.

But for SETTINGS_QPACK_BLOCKED_STREAMS (0x7) there is no associated QPACK instruction. I was assuming this would only be set once at creation and then not changed again, this is why it is an argument in the QpackEncoder constructor. But I don't see a problem with adding a setter for it.

sbordet added a commit that referenced this issue Feb 22, 2022
Now properly handling QPACK and HTTP/3 settings.

Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
@sbordet sbordet linked a pull request Feb 22, 2022 that will close this issue
sbordet added a commit that referenced this issue Feb 23, 2022
sbordet added a commit that referenced this issue Feb 23, 2022
Now properly handling QPACK and HTTP/3 settings.

Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug For general bugs on Jetty side
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants