| commit | 644063f500c4049a80bad276de00bf15ed7ab160 | [log] [tgz] |
|---|---|---|
| author | diannahu <diannahu@google.com> | Thu Mar 17 07:57:01 2022 -0700 |
| committer | Copybara-Service <copybara-worker@google.com> | Thu Mar 17 07:57:40 2022 -0700 |
| tree | 4e0aab0053696934c3f9648d8b6ee68085834c7f | |
| parent | 5f86c8c3f812d83c8bb3aa8bb4c114033260dadb [diff] |
Avoid invoking ExtensionVisitorInterface::OnSetting() for known SETTINGS parameters.
This CL changes Http2DecoderAdapter::OnSetting() to avoid calling
extension_->OnSetting() for known SETTINGS parameters (defined as
SpdyKnownSettingsId [1]). This change allows classes (e.g., OgHttp2Session) to
implement SpdyFramerVisitorInterface and ExtensionVisitorInterface without
having known SETTINGS parameters passed to them twice.
Archaeology shows prior state as:
1. SpdyFramerVisitorInterface::OnSetting() only accepted known SETTINGS;
ExtensionVisitorInterface::OnSetting() only accepted unknown SETTINGS.
2. Both OnSetting()s accepted known and unknown SETTINGS as of cl/186393706.
3. This CL causes ExtensionVisitorInterface::OnSetting() to only accept
unknown SETTINGS; SpdyFramerVisitorInterface::OnSetting() still accepts
known and unknown SETTINGS.
Note that Http2SettingsFields has a method IsSupportedParameter() [2], but that
would return false for certain SETTINGS parameters like
SETTINGS_ENABLE_CONNECT_PROTOCOL that we do not want to send to the
ExtensionVisitorInterface. Thus, this CL opts for ParseSettingsId() instead and
adds coverage to SpdyFramerTest.ReadKnownAndUnknownSettingsWithExtension.
This CL should be a functional no-op because production
ExtensionVisitorInterface::OnSetting() implementations currently check only for
the METADATA SETTINGS parameter, which would still be considered unknown.
[1] http://google3/third_party/spdy/core/spdy_protocol.h;l=139-162;rcl=387836338
[2] http://google3/third_party/http2/http2_structures.h;l=214;rcl=434624268
PiperOrigin-RevId: 435345949
QUICHE stands for QUIC, Http/2, Etc. It is Google‘s production-ready implementation of QUIC, HTTP/2, HTTP/3, and related protocols and tools. It powers Google’s servers, Chromium, Envoy, and other projects. It is actively developed and maintained.
There are two public QUICHE repositories. Either one may be used by embedders, as they are automatically kept in sync:
To embed QUICHE in your project, platform APIs need to be implemented and build files need to be created. Note that it is on the QUICHE team's roadmap to include default implementation for all platform APIs and to open-source build files. In the meanwhile, take a look at open source embedders like Chromium and Envoy to get started:
To contribute to QUICHE, follow instructions at CONTRIBUTING.md.
QUICHE is only supported on little-endian platforms.