- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Mon, 1 Jul 2019 09:41:36 +0300 (EEST)
- To: HTTP Working Group <ietf-http-wg@w3.org>
- CC: Felipe Gasper <felipe@felipegasper.com>, Alan Egerton <eggyal@gmail.com>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>
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
Received on Monday, 1 July 2019 06:42:09 UTC