- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Wed, 14 Dec 2016 10:51:20 +0000
- To: Julian Reschke <julian.reschke@gmx.de>
- cc: Alexey Melnikov <alexey.melnikov@isode.com>, Matthew Kerwin <matthew@kerwin.net.au>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Ilari Liusvaara <ilariliusvaara@welho.com>, HTTP working group mailing list <ietf-http-wg@w3.org>, Poul-Henning Kamp <phk@varnish-cache.org>
-------- In message <95057a05-6714-9154-8cf8-7cd302c86715@gmx.de>, Julian Reschke writes : >>> IETF has published BCP 137, which should be followed, unless there is a >>> very good reason not to: >>> https://www.rfc-editor.org/bcp/bcp137.txt >>> >>> See section 5.1. >> >> So many RFCs, so little time... >> >> EmbeddedUnicodeChar = %x5C.75.27 4*6HEXDIG %x27 >> >> That works for me, but HPACK is not a big fan of it: >> >> 19 + 6 + 11 + [4:6] * [5:6] + 11 = [67:83] >> >> Is that a show-stopper for anybody in Asia ? > >Why are we concerned with HPACK? Wouldn't we convert to raw UTF-8 before >HPACKing? Well, UTF-8 would also go through HPACK, but by eye-ball it seems that it would be more efficient. But it would kill the "HPACK doesn't molest tunneled H1 headers" idea ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Received on Wednesday, 14 December 2016 10:51:53 UTC