Skip to main content

1.3. HTTP Message Transformations

1.3. HTTP Message Transformations​

As mentioned earlier, HTTP explicitly permits, and in some cases requires, implementations to transform messages in a variety of ways. Implementations are required to tolerate many of these transformations. What follows is a non-normative and non-exhaustive list of transformations that could occur under HTTP, provided as context:

  • Reordering of fields with different field names (Section 5.3 of [HTTP]).

  • Combination of fields with the same field name (Section 5.2 of [HTTP]).

  • Removal of fields listed in the Connection header field (Section 7.6.1 of [HTTP]).

  • Addition of fields that indicate control options (Section 7.6.1 of [HTTP]).

  • Addition or removal of a transfer coding (Section 7.7 of [HTTP]).

  • Addition of fields such as Via (Section 7.6.3 of [HTTP]) and Forwarded (Section 4 of [RFC7239]).

  • Conversion between different versions of HTTP (e.g., HTTP/1.x to HTTP/2, or vice versa).

  • Changes in case (e.g., "Origin" to "origin") of any case- insensitive components such as field names, request URI scheme, or host.

  • Changes to the request target and authority that, when applied together, do not result in a change to the message's target URI, as defined in Section 7.1 of [HTTP].

Additionally, there are some transformations that are either deprecated or otherwise not allowed but that could still occur in the wild. These transformations can still be handled without breaking the signature; they include such actions as:

  • Use, addition, or removal of leading or trailing whitespace in a field value.

  • Use, addition, or removal of obs-fold in field values (Section 5.2 of [HTTP/1.1]).

We can identify these types of transformations as transformations that should not prevent signature verification, even when performed on message components covered by the signature. Additionally, all changes to components not covered by the signature should not prevent signature verification.

Some examples of these kinds of transformations, and the effect they have on the message signature, are found in Appendix B.4.

Other transformations, such as parsing and reserializing the field values of a covered component or changing the value of a derived component, can cause a signature to no longer validate against a target message. Applications of this specification need to take care to ensure that the transformations expected by the application are adequately handled by the choice of covered components.

Last updated on