API

strictHeaderParsing

This behavior specifies how the edge servers should handle requests containing improperly formatted or invalid headers that don’t comply with RFC 9110.

Some clients may send invalid or incorrectly-formatted, non-RFC-compliant request headers. If such requests reach the origin server, this vulnerability can be exploited by a “bad actor”, for example to poison your cache and cause invalid content to be returned to your end users. Use Strict Header Parsing to tell the edge servers what requests to reject, independently of the ​Akamai​ platform's default behavior. Therefore, you may either get the protection earlier than the global customer base or defer changes to a later time, though not recommended. Note that the two modes are independent – each of them concerns different issues with the request headers. For both options, a warning is written to the edge server logs whether the option is enabled or disabled.

As Akamai strives to be fully RFC-compliant, you should enable both options as best practice.

Enabling both options ensures that Akamai edge servers reject requests with invalid headers and don’t forward them to your origin. In such cases, the end user receives a 400 Bad Request HTTP response code.

OptionTypeDescriptionRequires
valid​Modeboolean

Rejects requests made with non-RFC-compliant headers that contain invalid characters in the header name or value or which contain invalidly-folded header lines. When disabled, the edge servers allow such requests, passing the invalid headers to the origin server unchanged.

{"displayType":"boolean","tag":"input","type":"checkbox"}
strict​Modeboolean 
Rejects requests made with non-RFC-compliant, improperly formatted headers, where the header line starts with a colon, misses a colon or doesn’t end with CR LF. When disabled, the edge servers allow such requests, but correct the violation by removing or rewriting the header line before passing the headers to the origin server.
{"displayType":"boolean","tag":"input","type":"checkbox"}