8 Notes
8.1 Known Issues and Limitations
Support for HTTP/2 requires Racket 8.1 or later, because previous versions of Racket’s openssl bindings do not support ALPN.
HTTP/2 without TLS (aka, “h2c”)
the CONNECT method
the Upgrade header field (HTTP/1.1) —
Note: the HTTP/2 protocol disallows Upgrade. Informational (1xx) responses —
This library silently discards Informational (1xx) responses. the Expect: 100-continue header field —
It is allowed, but this library ignores any 100 Continue response (see previous), and it never delays sending the request message body. “server push” streams (PUSH_PROMISE) (HTTP/2) —
The client’s initial SETTINGS frame at connection startup disables the feature. stream priorities (HTTP/2)
various limits on protocol elements, with reasonable defaults
flow control window sizes (HTTP/2)
HPACK indexing policy, including never-index fields (HTTP/2)
8.2 Logging
http —
about high-level client operations, connection creation and management, and dispatching to HTTP/1.1 or HTTP/2 implementations http1 —
about connections, request, and responses using the HTTP/1.1 protocol http2 —
about connections, streams, requests, and responses using the HTTP/2 protocol
8.3 Miscellaneous Notes
Accept-Encoding: gzip, deflate
User-Agent: racket-http123/lib-version
In general, the functions and methods of this library are thread-safe but not kill-safe. For example, killing a thread that is using a client object has a small chance of damaging the client object so that future operations block forever.
Responses are not bound to specific clients. It may be useful to fetch a response with one client and handle it (or handle redirections) with another client.
8.4 Synchronizable Event Results
This library uses (evt/c (-> X)) to communicate the result of an asynchronous process that normally produces an X but may fail. The synchronization result is a constant function (or at least a function that behaves like a constant function; calling it the first time may perform work, but subsequent calls return the same result) in the success case, or a function that raises an exception in the failure case.
An alternative would be (evt/c X); this can be implemented on top of the existing behavior by (wrap-evt evt (lambda (p) (p))). The disadvantage to this approach is that it cannot be further wrapped with exception-handling code. That is, a user that syncs on multiple such events cannot tell which one raised the exception.
8.5 HPACK Indexing Policy
HPACK (the compression scheme for HTTP/2 headers) is designed to reduce
vulnerability to attacks like CRIME,
which can discover secrets in headers by injecting data into the header and
observing the effectiveness of header compression. Part of this defense is
intrinsic, but HPACK additionally allows senders to choose which header fields
are “indexed”—
This library indexes Authorization and Cookie fields by default. In general, it does not mark any header fields as not-indexed based on security rationale, although it does avoid indexing for other reasons. For example, it does not index If-Modified-Since header fields, since they are unlikely to have the same value from request to request.
Users of this library should follow this policy: If a request has a header field with secret data, then the user should not allow an untrusted source to influence the value of the same header field in any other request made on the same connection. For example, if you make (or might make) a request with an Authorization header field containing your password, you should not make any other requests on the same connection with an Authorization header whose value is influenced by an untrusted party.
Future versions of this library may make the indexing policy configurable.
See the HPACK Security Considerations for more details.