Skip to main content

2.2. Derived Components

2.2. Derived Components

In addition to HTTP fields, there are a number of different components that can be derived from the control data, signature context, or other aspects of the HTTP message being signed. Such derived components can be included in the signature base by defining a component name, possible parameters, message targets, and the derivation method for its component value.

Derived component names MUST start with the "at" (@) character. This differentiates derived component names from HTTP field names, which cannot contain the @ character as per Section 5.1 of [HTTP]. Processors of HTTP message signatures MUST treat derived component names separately from field names, as discussed in Section 7.5.1.

This specification defines the following derived components:

@method The method used for a request (Section 2.2.1).

@target-uri The full target URI for a request (Section 2.2.2).

@authority The authority of the target URI for a request (Section 2.2.3).

@scheme The scheme of the target URI for a request (Section 2.2.4).

@request-target The request target (Section 2.2.5).

@path The absolute path portion of the target URI for a request (Section 2.2.6).

@query The query portion of the target URI for a request (Section 2.2.7).

@query-param A parsed and encoded query parameter of the target URI for a request (Section 2.2.8).

@status The status code for a response (Section 2.2.9).

Additional derived component names are defined in the "HTTP Signature Derived Component Names" registry (Section 6.4).

Derived component values are taken from the context of the target message for the signature. This context includes information about the message itself, such as its control data, as well as any additional state and context held by the signer or verifier. In particular, when signing a response, the signer can include any derived components from the originating request by using the req parameter (Section 2.4).

request: Values derived from, and results applied to, an HTTP request message as described in Section 3.4 of [HTTP]. If the target message of the signature is a response, derived components that target request messages can be included by using the req parameter as defined in Section 2.4.

response: Values derived from, and results applied to, an HTTP response message as described in Section 3.4 of [HTTP].

request, response: Values derived from, and results applied to, either a request message or a response message.

A derived component definition MUST define all target message types to which it can be applied.

Derived component values MUST be limited to printable characters and spaces and MUST NOT contain any newline characters. Derived component values MUST NOT start or end with whitespace characters.