On this page:
8.1 Known Issues and Limitations
8.2 Logging
8.3 Miscellaneous Notes
8.4 Synchronizable Event Results
8.5 HPACK Indexing Policy
8.12

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.

The following features are currently unsupported:
  • 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

There are various things that should be configurable that currently are not. A few examples:
  • flow control window sizes (HTTP/2)

  • HPACK indexing policy, including never-index fields (HTTP/2)

8.2 Logging🔗ℹ

This library logs on the following topics:
  • 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🔗ℹ

A client automatically adds the following header fields, unless they overridden by user-supplied fields:
  • 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”—that is, entered into the dynamic compression table, to further protect secret header data. For example, some HTTP/2 client libraries automatically mark Authorization fields and short Cookie fields as not-indexed, since they might contain low-entropy secret data.

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.