Re: HTTP/2 Server Push and solid compression

[Kari Hurtta <[e-mail]>]

https://lists.w3.org/Archives/Public/ietf-http-wg/2019AprJun/0175.html

> > Possibly … does h2 multiplexing use a separate compression context for each stream, or does it 
> > funnel each message through the same context?
> 
> HPACK (Header Compression for HTTP/2) uses one context for all streams.
> 
> This is processed when HEADERS or CONTINUATION frame is received. HEADERS frame is also used when
> stream is opened.
> 
> Frames on HTTP/2 are processed sequentially because it is transported over TCP. So there is
> no problem with out of order access of header compression context.


Similar compressed frame is possible for http responses, when

• compression context is selected by application
• compression is done by http stack just before response frame
  is written to tcp socket (this means that compresion can
  not done in advance, but after http priority selection;
  this means delay to socket write) ; http stack may 
  sill select to not use compression even when application
  is selected compression context for response
• decompression is done when compressed frame is read from
  TCP sockect, similar than header compresison is decoded
  when HEADERS frame is read from sockect. Therefore there
  is no problem with out of order access for selected
  compression context.

• decompression must be done also for discarded streams (this
  is similar than HEADERS frame processing) because compression
  context must be updated.

• application is resposible to register compression context
  for http stack and tell if respponse uses compression context
  and give compression context. It is only safe to use 
  compression context for static responses (mostly
  http push responses) which does not depend request context.
• compressed reponse frame includes compression context id
• natutarally there need frames from allocation and deallocation
  of compression. http stack passes these to other end when
  application registeres and deresiters compression context
  for responses from http stack

• compression method must allow explicit compression context
  and mixing responses from different responses that way 
  that compressed frame produces always part of response data
  for just for one http response even when sama compression
  context is used for several responses (probably for http
  pushes from same stream).


I'n not sure that this is usefull, but it looks that
this is possible to specify.

That does not work for QUIC or HTTP/3.

/ Kari Hurtta