IETF HTTP Working Group Extensions

repository·main·Indexed 19 days ago

https://github.com/httpwg/http-extensions

Official working area for the IETF HTTP Working Group (HTTPWG) to develop draft specifications for HTTP extensions. Documentation includes specifications for Cache Groups (Cache-Groups and Cache-Group-Invalidation headers) and Compression Dictionary Transport (Use-As-Dictionary, Available-Dictionary, and Dictionary-ID headers), including content encodings dcb and dcz.

Tokens
48.1K
Snippets
74
Records
212
Agent score
67%

What's inside http-extensions

  1. Overview of the Early Hints HTTP extension

    main

    The Early Hints extension introduces an informational HTTP status code designed to convey hints to a client. These hints allow the client to make preparations (such as preloading resources) while waiting for the final response to be processed.

    Note: As of the current draft status, this extension is categorized as Experimental to facilitate deployment experience and gathering of real-world data.

  2. Access Draft HTTP Extension Specifications

    main

    The http-extensions repository serves as the working area for the IETF HTTP Working Group's extensions to the HTTP protocol. Developers can find the current list of specifications, including editors' drafts, document status, and associated issues, at the official HTTP extensions website.

    To view the specific drafts and their current status, visit the list of specifications.

  3. What is the WRAP_UP capsule and when to use it

    main

    The WRAP_UP capsule is a mechanism used by HTTP proxies to signal to a client that an upcoming request stream termination is imminent.

    Unlike GOAWAY (which signals connection termination), WRAP_UP is designed for scenarios where a proxy needs to terminate an individual long-lived request stream (e.g., for load balancing, maintenance, or enforcing data limits) while keeping the underlying connection active. This is particularly useful for tunneled connections like CONNECT or connect-udp, where an abrupt termination would cause truncated content and prevent the client from safely retrying requests.

    Key Use Cases:

    • Facilitating load balancing by migrating traffic.
    • Performing maintenance on a proxy without dropping the entire connection.
    • Imposing data usage limits on a specific stream.
    • Releasing resources associated with streams like HTTP Datagrams or WebTransport.
  4. What is the No-Vary-Search HTTP Caching Extension?

    main

    The No-Vary-Search extension allows origin servers to signal to HTTP caches (browsers, CDNs, forward proxies) that certain parts of a URL's query component do not semantically affect the response. This enables caches to reuse a stored response even if the query parameters differ, improving cache hit rates by ignoring non-semantic variations like parameter order or analytics tracking parameters.

    Key use cases:

    • Ignoring the order of query parameters.
    • Ignoring specific parameters used for analytics (e.g., utm_source).
    • Using an allowlist approach where only specific parameters are considered semantically significant.
  5. What is the Expect-CT HTTP header?

    main

    The Expect-CT HTTP header is an experimental mechanism that allows web host operators to instruct user agents (browsers) to expect valid Signed Certificate Timestamps (SCTs) during connections.

    Its primary purposes are:

    • To discover misconfigurations in Certificate Transparency (CT) deployments.
    • To ensure that any misissued certificates accepted by user agents are discoverable in CT logs.
  6. Overview of the Alt-Svc extension

    main

    The Alt-Svc (Alternative Services) extension provides a method for HTTP servers to inform clients about authoritative access to the same origin at a different network location or using a different protocol stack. This allows a client to discover multiple network or protocol endpoints for an origin that can serve content in different ways (e.g., switching from HTTP/1.1 to HTTP/2 or a different port/IP).

    Key characteristics:

    • Optionality: The behavior is fully optional for clients.
    • Discovery Methods: The specification defines two primary ways for a client to learn about alternatives (though future extensions like DNS may exist).
    • Parameter Handling: Parameters used to modify properties of Alt-Svc listings are optional-to-understand. If a client encounters a parameter it does not recognize, it should ignore that specific parameter rather than discarding the entire entry.
  7. What is the Unencoded-Digest field and when to use it

    main

    The Unencoded-Digest field is used to communicate integrity digests calculated from the unencoded representation of a message (i.e., the data after all Content-Encoding transformations have been stripped away).

    This is useful when:

    • An application receives data that has been transparently decoded (e.g., by a browser) and wants to verify integrity without re-encoding the data.
    • A client is performing HTTP Range Requests and needs to verify the integrity of the 'stitched-together' whole without decoding and re-encoding individual parts.
    • You want to avoid the complexity and performance cost of re-encoding data to match a Repr-Digest or Content-Digest that was calculated on encoded bytes.
    /* Example of an Unencoded-Digest field for the string "An unexceptional string\n" */
    Unencoded-Digest: sha-512=:WjyMuMD9EI/v0RoJchcevbo6lF498VyE9564OgXf+98iJptoSvb1Czo9uVJu2bVU/tOv90huiMG3+YaMX1kipw==:
  8. Overview of running WebSockets over HTTP/2

    main
    The draft-ietf-httpbis-h2-websockets specification defines a mechanism to run the WebSocket Protocol over a single stream of an existing HTTP/2 connection. This approach enables WebSockets to function on HTTP/2 servers, which can reduce operational issues for websites by consolidating traffic over a single connection.
  9. How HTTP cookies work (Set-Cookie and Cookie)

    main

    HTTP cookies allow servers to maintain state in a stateless protocol.

    1. Server to User Agent: The server sends the Set-Cookie header in an HTTP response containing name/value pairs and metadata (attributes).
    2. User Agent to Server: In subsequent requests, the user agent uses the stored metadata to determine if it should return those name/value pairs in a single Cookie header field.

    Key behaviors:

    • Scope: Servers can control the cookie's scope using Path and Domain attributes.
    • Security: Attributes like Secure and HttpOnly provide additional protections.
    • Persistence: The Expires attribute determines if a cookie persists across sessions.
    • Case Sensitivity: Cookie names are case-sensitive; SID and sid are treated as two distinct cookies.
    == Server -> User Agent ==
    Set-Cookie: SID=31d4d96e407aad42
    
    == User Agent -> Server ==
    Cookie: SID=31d4d96e407aad42
  10. Handle concurrency and race conditions in resumable uploads

    main

    Resumable uploads do not permit parallel requests for the same upload. A client MUST NOT perform multiple representation data transfers for the same upload resource in parallel, nor perform transfers while the creation of the same upload resource is still in progress.

    To prevent race conditions, data loss, or corruption caused by network interruptions (where a client retries while a server still considers the previous request ongoing), servers should follow these guidelines:

    • Recommended Approach: If a server receives a new request (to retrieve offset, append data, or cancel) while a previous creation or append request is still ongoing, the server SHOULD terminate the previous request before processing the new one. The server MAY abruptly terminate the previous HTTP connection or stream.
    • Alternative Approach: The server can implement an access lock, processing new requests only after all previous requests have been completed. However, this may cause friction if a network interruption causes a request to hang, preventing the client from resuming quickly.
  11. Use the 451 Legally Restricted Status Code

    main
    The HTTP status code 451 is used when access to a resource is denied due to legal demands or restrictions. This status code provides a machine-readable indicator that an automated client can detect, which is useful for services like Lumen (formerly Chilling Effects) to track and report legal censorship or restricted content.
  12. Understand Compression Dictionary Transport

    main

    Compression Dictionary Transport is an HTTP mechanism that allows clients and servers to use specific HTTP responses as external dictionaries for future requests. This enables dictionary-based compression (using schemes like Brotli or Zstandard) to reduce transmitted data size, often through delta compression.

    There are two primary use cases:

    1. Version Upgrade: Using a previous version of a resource (e.g., app.v1.js) as a dictionary to compress a newer version (e.g., app.v2.js).
    2. Common Content: Using a shared resource (like a common HTML template or API schema) as a dictionary for multiple different responses that share similar patterns.