#445: Transfer-codings - Alternate proposal

Below I've attempted to capture...

- the problems we are trying to solve with transport codings, and

- the issues with transport codings brought up in the threads.



Problems solved with transport codings...

  a) Allows compression of identity range requests [1-4]

  b) De-emphasizes on-the-fly C-E & associated issues [2, 5-6]

  c) Allows extensibility to new/better compression techniques  [7]

  d) Allows compression by intermediaries (e.g. Roy suggests CDNs could be more efficient this way [8]) (e.g. Amos seems to claim this can be a security benefit by doing hop-specific compression [9])



Issues with using transport codings...

  0) Various security issues (e.g. DoS) [10-18].

  1) Compression at a hop without context about the data. [18-22]

  2) Requires a frame format change* [23]

  3) 2-byte tax in every frame* [23]

  4) Results in a low compression factor if done frame-by-frame* [24]

  5) Reintroduces hop-by-hop headers** [9, 25-26]

  6) Poses a problem for adding signed headers in a future rev** [9]

  7) Implementation complexity [15]

  8) Disputed benefit of compression by CDNs [17]

 9) Many seem to simply hate TE/Transfer-Encoding (for whatever reason) [22-23, 27]

*Specific to Matthew's proposal [28]

**Specific to our proposal [29]



Below we suggest two potential solutions to these issues. Other suggested solutions are welcome. (Also, please also let me know if you think I failed to capture any of the issues already brought up.)



A potential Solution

- Issues 2-4 are w.r.t. Matthew's proposal so I'll let him address those concerns.

- We could simply solve issues 0, 1, 5, 6, 8 by adding a special restriction in HTTP/2 on Transfer-Encoding headers disallowing changes at any hop.  Essentially making Transfer-Encoding end-to-end. This is a bit ugly though because it changes semantics and would likely cause confusion. (Matthew also mentioned doing something similar for his proposal, but he didn't get much positive support [30].)

- I have no answer for issue 9.  Haters are gonna hate.



A potentially better Solution

- A variation on the above solution would be to introduce a new end-to-end coding called "Message-Encoding".  The key difference between "Content-Encoding" (C-E) and "Message-Encoding" (M-E) would be that C-E comes before the Range is applied and M-E comes after the Range is applied.

  + M-E would allow seeks (i.e. range requests) on the identity data and allow the partial content to be compressed.

  + The decision to compress is in exactly the same place as the decision for C-E. The server will be able to decide the most suitable technique for a particular situation (i.e. C-E or M-E).

  + M-E would also be the better, more natural, choice for on-the-fly compression because range requests wouldn't require the entire content to be compressed just to serve a portion of it.

  - The only downside is that intermediaries couldn't add compression, but nobody seems to be fighting strongly for that (ourselves included).



Although I know HTTP/2 isn't allowed to change the existing semantics of HTTP, it's not clear if adding HTTP/2 specific semantics is allowed??





References

[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/1179.html Keith

[2] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0075.html Matthew

[3] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0104.html Matthew

[4] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/1188.html Roland

[5] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/1199.html Roland

[6] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/1214.html Matthew

[7] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0067.html Matthew

[8] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/1189.html Roy

[9] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0098.html Amos

[10] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0071.html Martin

[11] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0083.html Martin

[12] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0078.html Michael

[13] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0079.html Michael

[14] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0088.html Michael

[15] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0103.html Roberto

[16] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0105.html Roberto

[17] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/1197.html Mark

[18] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0087.html Michael

[19] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0086.html Martin

[20] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/1204.html Martin

[21] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0089.html Michael

[22] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/1221.html Poul-Henning

[23] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0065.html Mark

[24] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0100.html Roland

[25] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0084.html Martin

[26] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0082.html Martin

[27] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/1206.html Patrick

[28] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0059.html Matthew

[29] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0076.html Keith

[30] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0080.html Matthew



This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.