Should Line Folding get replaced by spaces?

[spease]

Noticed this in RFC-7230:

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.

I think currently httparse will just reject a line fold. This paragraph seems to suggest it should reinterpret it with spaces. Is this interpretation correct?

I am running into this problem (and an invalid SOH character) with an internal server.

Thanks.

[seanmonstar]

Yes, it "should" handle line folds. I've purposefully left it out for a few reasons:

• It's very very rare.
• It's deprecated, so new implementations should NEVER write it, and old ones should upgrade.
• Because of those, I didn't want the performance cost or code complexity of supporting it.

[tari]

I've encountered this problem while working on a WARC parser, where that format specifies definitions compatible with RFC2616. There's a WARC proposal to forbid implementers of a future version from writing folded lines, but readers would still need to be able to handle the old version for backwards compatibility.

---

I appreciate the complexity of supporting some of the weird corners of header syntax, but it's a shame if httparse never supports those since it means potential users will have to roll their own parsers if that functionality is important. If this effectively means that the library is designed for server use only that would be reasonable, but it would be good to document that limitation.