Skip to main content

4.7. Specifying HTTP Header Fields

4.7. Specifying HTTP Header Fields​

Applications often need to define new HTTP header fields. When they do, they MUST register them in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" following the procedure in [HTTP] Section 16.3.

[STRUCTURED-FIELDS] provides a standardized way to define header field values, making it easier to parse and handle them. Applications SHOULD use Structured Fields when defining new header fields.

When defining header fields, applications need to consider:

  • The header field name SHOULD be descriptive and follow the naming conventions in [HTTP] Section 16.3.1.

  • Header fields SHOULD NOT use the "X-" prefix, as per [RFC6648].

  • The header field's value syntax SHOULD be clearly specified. Using [STRUCTURED-FIELDS] is recommended.

  • The header field's semantics SHOULD be clearly explained, including when it should be sent and how it should be interpreted.

  • Applications SHOULD consider whether the header field should be hop-by-hop or end-to-end. Most application-defined header fields should be end-to-end.

  • Applications SHOULD specify what happens if the header field appears multiple times in a message.

  • Applications SHOULD specify whether the header field is intended for requests, responses, or both.

Applications SHOULD reuse existing header fields where possible rather than defining new ones. For example, if an application needs to identify the type of content being sent, it should use Content-Type rather than defining a new header field.

When reusing existing header fields, applications MUST respect their defined semantics and syntax.

Last updated on