Freigeben über

2.2.5 HTTP Header Fields

  • Artikel

The OData protocol uses existing headers as specified in [RFC2616] as well as custom HTTP headers that are defined in this document. Some of the headers that are specified in [RFC2616] are further restrained in how they can be used, as specified in this document. These additionally restrained headers and the custom headers are defined in this section.

Unless otherwise specified, the headers that are defined in this document and any tokens (also called tags or directives) that are used on those headers are defined for use on both requests and responses.

If a client or server receives an HTTP header that is not defined in this section or if the header is not defined in the current context (for example, a request-only header is received in a response), the header MUST be ignored, as specified in [RFC2616].

If a client or server receives an HTTP header that is defined in this section and the header contains an unknown or malformed token, as specified in this section, the request or response that contains the header MUST be considered malformed.

If a client or server receives an HTTP header that is defined in this section, but the header contains a token that is not defined in the current context (for example, a request-only token is received in a response), the request or response that contains the header and token MUST be considered malformed.

This section defines the syntax of the HTTP headers that are defined in this section by using the Augmented Backus-Naur Form (ABNF) syntax, as specified in [RFC5234]. Any ABNF syntax rules that are not specified in [RFC5234] use the ABNF extensions that are specified in [RFC2616].

The grammar in this section is word-based. Except where noted otherwise, linear white space (LWS), as specified in [RFC2616], can be included between any two adjacent words (token or quoted-string) and between adjacent words and separators without changing the interpretation of a field. At least one delimiter (LWS and/or separators) MUST exist between any two tokens, as specified in [RFC2616], because they would otherwise be interpreted as a single token.