Open vytautaskubilius opened 1 month ago
https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.4
According to this, folded headers are obsolete and a bad request is appropriate. Wdyt?
Thanks for pointing that out - I hadn't noticed the link to the newer RFC. Reading through that though I still think that in this case parsing the folded value instead of returning an error would be more appropriate. The RFC only provides a single option for user agents receiving the headers in a response:
A user agent that receives an obs-fold in a response message that is
not within a message/http container MUST replace each received
obs-fold with one or more SP octets prior to interpreting the field
value.
That same option is also valid for servers and proxies, so doing that should account for all use cases.
I'm kind of curious about what servers are generating such a response in a production environment.
Are you able to provide more details?
I'd be willing to accept a PR to implement this (conversion of obs-fold with spaces) but I'm slightly against it as it is deprecated behaviour.
we integrate with many 3rd party APIs, and one of them (an IoT hardware company from the UK) is returning a header with an obs-fold value, so we're seeing the following error:
Protocol::HTTP1::BadHeader
Could not parse header: "Strict-Transport-Security: max-age=31536000;\n\t\t\t includeSubDomains; preload"
What about reporting a bug to them too?
I’m afraid that’s not a reliable (and potentially not scalable) option for a couple of reasons:
async-http-faraday
, which would mean that we would have to keep reverting the migration until we manage to catch all such issues. I would be happy to accept a PR to parse folded headers.
When receiving a response with a header that is folded over multiple lines, the following error is returned:
I first noticed this issue when trying to migrate to using the
async-http-faraday
adapter - some requests to external APIs started returning these responses. I was able to reproduce this behaviour by adapting the example from the readme with a simple localhost NGINX server that returns a multi-line header:repro.rb
nginx.conf
Start an NGINX container with this configuration and run the repro script to observe the error:
The HTTP/1.1 specs indicate that multiline header values are acceptable as long at they start with horizontal tabs or spaces: