RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 8188, "Encrypted Content-Encoding for HTTP", June 2017

Source of RFC: httpbis (wit)

Errata ID: 8620
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Patrick Barrett
Date Reported: 2025-10-30

Section 3.1 says:

   The encrypted data in this example is the UTF-8-encoded string "I am
   the walrus".  The input-keying material is the value "yqdlZ-
   tYemfogSmv7Ws5PQ" (in base64url).  The 54-octet content body contains
   a single record and is shown here using 71 base64url characters for
   presentation reasons.

   HTTP/1.1 200 OK
   Content-Type: application/octet-stream
   Content-Length: 54
   Content-Encoding: aes128gcm

   I1BsxtFttlv3u_Oo94xnmwAAEAAA-NAVub2qFgBEuQKRapoZu-IxkIva3MEB1PD-
   ly8Thjg

It should say:

   The encrypted data in this example is the UTF-8-encoded string "I am
   the walrus".  The input-keying material is the value "yqdlZ-
   tYemfogSmv7Ws5PQ" (in base64url).  The 54-octet content body contains
   a single record and is shown here using 72 base64url characters for
   presentation reasons.

   HTTP/1.1 200 OK
   Content-Type: application/octet-stream
   Content-Length: 54
   Content-Encoding: aes128gcm

   I1BsxtFttlv3u_Oo94xnmwAAEAAA-NAVub2qFgBEuQKRapoZu_ul1ATXXzhZ8IY
   2l5S6w8cG

Notes:

The example is missing the padding delimiter octet.

The paragraph directly above this explicitly says it should have it.

> [...] This uses a
> record size of 4096 octets and no padding (just the single-octet
> padding delimiter), so only a partial record is present.

Also, without that the delimiter, the body is only 53 octets, not the 54 the description says it should be.

Report New Errata



Advanced Search