Greetings,
We have been successfully using Hapi.js (version 16.1.0 on Node 6.9.1 and Debian Jessie) in production for a while now.
Recently however we encountered strange entries in our logs. Specifically we started seeing a bunch of the following entries:
Error: Unknown encoding Error: Invalid accept-encoding header
After much digging we where able to reproduce the issue using the following curl command
POC and details removed by hapi contributor
It then seems like Hapi is using the Boom object as the actual encoding with ultimately makes the framework fail the following assertion (in lib/compression.js)
Hoek.assert(encoder !== undefined, `Unknown encoding ${encoding}`);The end-result is that the client that initiated the (erroneous) request is left hanging, since the framework never responds.
Personally I don't care one bit about the client not receiving a response, however the fact that no response is produced results in various error logs in Internet-facing reverse proxies (in the form of timeouts).
I could create a PR that fixes this issue, but am hesitant to do so since I don't know what the behavior should be in this case.
Should the appropriate response be an HTTP 400 response, or something else (like using one of the correctly specified encodings)?
It seems to me however that the current (non-) handling of such erroneous requests is not the desired behavior.
Regards,
George
Greetings,
We have been successfully using Hapi.js (version
16.1.0on Node6.9.1andDebian Jessie) in production for a while now.Recently however we encountered strange entries in our logs. Specifically we started seeing a bunch of the following entries:
After much digging we where able to reproduce the issue using the following curl command
POC and details removed by hapi contributorIt then seems like Hapi is using the Boom object as the actual encoding with ultimately makes the framework fail the following assertion (in
lib/compression.js)The end-result is that the client that initiated the (erroneous) request is left hanging, since the framework never responds.
Personally I don't care one bit about the client not receiving a response, however the fact that no response is produced results in various error logs in Internet-facing reverse proxies (in the form of timeouts).
I could create a PR that fixes this issue, but am hesitant to do so since I don't know what the behavior should be in this case.
Should the appropriate response be an HTTP 400 response, or something else (like using one of the correctly specified encodings)?
It seems to me however that the current (non-) handling of such erroneous requests is not the desired behavior.
Regards,
George