thank you for reading my question. I have read numerous documents about HTTP/2 and tried to understand most important concepts for constructing a APNs server-side API in Java.
APNs requires the use of HPACK (header compression for HTTP/2), which prevents repeated header keys and values. APNs maintains a small dynamic table for HPACK. To help avoid filling up the APNs HPACK table and necessitating the discarding of table data, encode headers in the following way—especially when sending a large number of streams:
If I have understood correctly, I need to use Huffman Encoding for the header compression. If I am wrong on this, please correct me.
The :path value should be encoded as a literal header field without indexing
The authorization request header, if present, should be encoded as a literal header field without indexing
I read RFC 7541 for this, but have no idea what they are talking about. Please note that I am trying to understand the system and requirements to gain knowledge through this post, not just answers to the specific questions.
The appropriate encoding to employ for the apns-id, apns-expiration, and apns-collapse-id request headers differs depending on whether it is part of the initial or a subsequent POST operation, as follows:
The first time you send these headers, encode them with incremental indexing to allow the header names to be added to the dynamic table
Subsequent times you send these headers, encode them as literal header fields without indexing
What do they mean when they say, "encode them with incremental indexing to allow the header names to be added to the dynamic table" and "Subsequent times you send these headers, encode them as literal header fields without indexing" afterwards. I guess understanding one of two literal header fields with/out indexing will help me comprehend this better.
Thank you again for reading the question and please help me with this!!
I think you will be better off using a Java library that does HTTP/2 for you.
The Jetty HttpClient (disclaimer, I'm the maintainer) does exactly that, see here.
If instead you want to implement HPACK because you want to have fun, then you have to take your time and read carefully RFC 7541. As an starting point for implementing it, you can read the many Java implementations of HPACK out there, from Jetty's to Netty's, Undertow's, etc.
All the questions you are asking (e.g. "what is a 'literal header field without indexing') are detailed in the RFC in their own sections.
Very coarsely, HPACK defines a mapping table that maps numbers to strings. Both peer maintain this table in sync, so that the two tables always contain the same data (at rest).
When one peer sends a HPACK block, it sends the numbers, so that the receiving peer can use the numbers to access the HPACK table to obtain the strings.
For new/custom headers (think cookies), the sending peer sends the number and the string, so that the receiving peer can update its HPACK table. For the first time there is no compression, but the second time that the same header is sent, the sending peer just sends the number, since it knows that the other peer will have the string mapped already, and this gives good compression of HTTP headers.