7.2.3. Choosing Message Components

7.2.3. Choosing Message Components

Applications of HTTP message signatures need to decide which message components will be covered by the signature. Depending on the application, some components could be expected to be changed by intermediaries prior to the signature's verification. If these components are covered, such changes would, by design, break the signature.

However, this document allows for flexibility in determining which components are signed precisely so that a given application can choose the appropriate portions of the message that need to be signed, avoiding problematic components. For example, a web application framework that relies on rewriting query parameters might avoid using the @query derived component in favor of sub-indexing the query value using @query-param derived components instead.

Some components are expected to be changed by intermediaries and ought not to be signed under most circumstances. The Via and Forwarded header fields, for example, are expected to be manipulated by proxies and other middleboxes, including replacing or entirely dropping existing values. These fields should not be covered by the signature, except in very limited and tightly coupled scenarios.

Additional considerations for choosing signature aspects are discussed in Section 1.4.