7.2.4. Choosing Signature Parameters and Derived Components over HTTP Fields

7.2.4. Choosing Signature Parameters and Derived Components over HTTP Fields

Some HTTP fields have values and interpretations that are similar to HTTP signature parameters or derived components. In most cases, it is more desirable to sign the non-field alternative. In particular, the following fields should usually not be included in the signature unless the application specifically requires it:

"date" The Date header field value represents the timestamp of the HTTP message. However, the creation time of the signature itself is encoded in the created signature parameter. These two values can be different, depending on how the signature and the HTTP message are created and serialized. Applications processing signatures for valid time windows should use the created signature parameter for such calculations. An application could also put limits on how much skew there is between the Date field and the created signature parameter, in order to limit the application of a generated signature to different HTTP messages. See also Sections 7.2.2 and 7.2.1.

"host" The Host header field is specific to HTTP/1.1, and its functionality is subsumed by the @authority derived component, defined in Section 2.2.3. In order to preserve the value across different HTTP versions, applications should always use the @authority derived component. See also Section 7.5.4.