...continued from part 3
RFC 9114 HTTP/3
10.1 Server Authority
HTTP/3 uses QUIC and TLS to verify the server authority. We always set endpoint identification algorithm to HTTPS to ensure that the server certificate identity is authoritative for the URL host name.
10.2 Cross-Protocol Attacks
The underlying TLS implementation ensures that both parties agree on the ALPN.
10.3 Intermediary-Encapsulation Attacks
HttpClient validates incoming field names and values. Responses containing invalid fields are treated as malformed, and are not delivered to the application.
10.4 Cacheability of Pushed Responses
HttpClient does not cache any responses.
The default PushPromiseHandler rejects push promises where the :authority header does not match the hostname that was used to establish the connection. Custom push promise handlers might choose to implement different checks.
10.5 Denial-of-Service Considerations
The number of PUSH_PROMISE frames is limited to a maximum of 100 concurrently used push IDs at any given time.
The maximum allowable SETTINGS frame size is limited to 1280 bytes, which is more than enough to hold all defined settings.
HttpClient does not monitor the use of unknown frame types and unknown stream types. H3_EXCESSIVE_LOAD error is not generated.
HttpClient limits the maximum size of a field section and the maximum size of a field.
10.6 Use of Compression
HttpClient does not support compression. The Accept-Encoding and Content-Encoding headers are not set by the client. They may be set by the application.
10.7 Padding and Traffic Analysis
No additional requirements.
10.8 Frame Parsing
HttpClient checks the frame lengths.
10.9 Early data
HttpClient does not implement 0-RTT
10.10 Migration
No additional requirements.
10.11 Privacy Considerations
No additional requirements.
continued in part 5...
No comments:
Post a Comment