HEADERS/CONTINUATION data point for CUPS and HTTP/2 (in case anyone is interested)

(Purposely not posting on the continuation thread; just some concrete data from running code here...)

As part of my Huffman unit tests I added some simulation of our worst-case Kerberos Authorization header values, where we have 64k of ticket data that produces a 87392 byte Base64-encoded value, including the "Negotiate" prefix...

I'm seeing a 20% reduction in size for these large Base64-encoded values with Huffman, translating into a compressed size of about 70k when encoded on-the-wire.  This is a long ways from 16k, and will mean that if I choose to implement CONTINUATION frames I'll need to split the value across 5 frames (!).

Conversely, if I limit Kerberos tickets to a little over 14k then I should be able to fit all of the normal request headers and the Authorization value in the initial HEADERS frame.  Beyond that I'll have to either punt or actually implement CONTINUATION support...

Without Kerberos I'm seeing at very small HEADERS frames - less than 512 bytes in most cases.  Overhead to encode/decode headers (including Huffman) seems manageable, but I haven't done any benchmarking (or optimization) to determine whether we'll take a hit compared to HTTP/1.1.  I'm keeping a journal on all of this in order to write something up when I'm all done...

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair