- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 31 Jul 2013 10:18:55 +0200
- To: HTTP Working Group <ietf-http-wg@w3.org>
Feedback for draft-ietf-httpbis-header-compression-01 Questions "4.2.1 Integer representation Integers are used to represent name indexes, pair indexes or string lengths. The integer representation keeps byte-alignment as much as possible as this allows various processing optimizations as well as efficient use of DEFLATE. For that purpose, an integer representation always finishes at the end of a byte." The mention of DEFLATE is kind of surprising here. "4.2.2 String literal representation Literal strings can represent header names or header values. They are encoded in two parts: The string length, defined as the number of bytes needed to store its UTF-8 representation, is represented as an integer with a zero bits prefix. If the string length is strictly less than 128, it is represented as one byte. The string value represented as a list of UTF-8 characters." By "list of UTF-8 characters" I assume you mean "octet sequence representing the UTF-8 encoding of the string"? A more general question: the proposal handles header field values as character sequences, whereas in HTTP/1.1 they are really octet sequences with an unknown character encoding scheme. That is, if you see octets >= 0x80 you really can't tell in general what they mean. At some point we'll have to decide how to handle this problem. "A. Initial header names" These need review, even without real-world data. In particular, we shouldn't have deprecated fields such as Keep-Alive or Content-MD5 here. Editorial HTTP header -> HTTP header field References: we really don't have any normative references??? Appendix B: avoid use of "X-" prefix; just call the header field "Example-Extension" or something like that. Finally, shouldn't this draft be in SVN or github? Best regards, Julian
Received on Wednesday, 31 July 2013 08:19:27 UTC