Hacker News Reader

This was mentioned in go's net/http by this CL: https://go-review.googlesource.com/c/go/+/17980/ it's an interesting point that the spec allows this.

View on HN

Note that the spec is stricter for field-name than for field-value. Field names are ASCII, while field values are latin1 (or mime encoded but no one cares about mime encoding).

And yes I have seen bytes in both names and values in the wild (where bytes in names are invalid but need to be handled gracefully, while bytes in values are effectively valid latin1 if only for legacy reasons)

Looking at the bug you linked to, looks like this almost bit them too. Here's the final field-value behavior they landed on: https://go-review.googlesource.com/c/go/+/18375/

With HTTP/2 you can theoretically even transmit bytes with all binary values inside them in both names and values - since the values are length-delimited.

Based on that, some implementations seem to restrict allowed values to the rules that you describe, while others don't.

Yeah, and really the moral of the story shouldn't be (just) to get good at parsing, but to assume that any two parsers may disagree on how to parse a piece of data as part of your security model.

Reply on news.ycombinator.com