You can get this Uptime Monitoring error in your Location Fail Log if your web server uses
HTTP/2 and responds with a connection-specific header field.
What is the issue?
RFC 7540 indicates that the
HTTP/2 response MUST NOT include connection-specific header fields, and if such headers exist, the response is considered malformed.
HTTP/2 does not use the Connection header field to indicate connection-specific header fields; in this protocol, connection- specific metadata is conveyed by other means. An endpoint MUST NOT generate an HTTP/2 message containing connection-specific header fields; any message containing connection-specific header fields MUST be treated as malformed (Section 220.127.116.11).
How to find the issue?
To find out which connection-specific header(s) your website is responding with, you can try to reproduce the cURL
Error 92 from any Linux server that has a modern cURL version installed (which supports
HTTP/2), by running the following command towards your website:
curl -v --http2 https://<YOUR_WEBSITE_HERE>
The above command will output the connection verbose text, which should end with an error similar to:
curl: (92) HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)
If this is the case, you’ll need to also look in the verbose text (towards the end) for an error similar to:
http2 error: Invalid HTTP header field was received: frame type: 1, stream: 1, name: [upgrade], value: [h2,h2c]
This last error will indicate the exact connection-specific header breaking the RFC 7540 standard and making the response be considered malformed/incorrect.
In the above example, the header is
How to fix the issue?
Fixing the issue must be done on your web server side. This web server must be configured to respect the RFC 7540 standard and not send any connection-specific headers back when using the
HTTP/2 protocol. This task will vary based on which web server you are using. You’d need to discuss this further with your web administrator or the tech team that handles your web server configuration.