4 ms·
> That's a terrible reason. Consider this: all strings are utf-8, so working with pure ASCII is much more work in golang. It leads to all kind of issues, not
by panpanna 6y ago
> That's a terrible reason.
Consider this: all strings are utf-8, so working with pure ASCII is much more work in golang.
It leads to all kind of issues, not only security problems.
- kerng 6y agoBut that's a Golang issue then, not http
- panpanna 6y agoI know, I am just trying to explain how this could happen :)
- deleted 6y ago[deleted]
- _-___________-_ 6y agoYes, but this simply means that header values are not (Go) strings, they're byte arrays. Many languages represent them this way, with a (fallible) function to get the string value iff the byte array contains valid UTF-8. The whole "it would be more work" as a justification for not doing things properly is one of the roots of the more general issues with Go I alluded to in my post above.
- 0xjnml 6y ago1) Go string type is specified as a sequence of bytes. Full stop. Any encoding, binary blob, string does not care. Particular stdlib string functions _do_ care, expect UTF-8 encoding and document the fact. Other stdlib string function work with the sequence as a sequence. 3) Go specification requires UTF-8 in only one place: the encoding of Go source files string literals. 2) Pure ASCII is a subset of UTF-8, ie. pure ASCII _is_ valid UTF-8. There is _no_ more work and there are _no_ security problems when working with pure ASCII as UTF-8, because that's what it is.