- From: Simone Bordet <simone.bordet@gmail.com>
- Date: Thu, 12 Jun 2014 19:29:11 +0200
- To: HTTP Working Group <ietf-http-wg@w3.org>
Hi, draft 12, section 6.1 states that "padding is included in flow control". A) Does this mean that, given 100 bytes of data and 300 bytes of padding: 1) the number that updates the flow control window is 400 (data + padding) 2) the number that updates the flow control window is 402 (pad_high + pad_low + data + padding) B) In the same example, let's assume that the stream has a remaining flow control window of 250. What should an implementation do ? 1) send a frame composed of: pad_low + 100 bytes of data + 149 bytes of padding 2) do not send a frame because the there is not enough window for the padding ? C) In the same example, let's assume that the stream has a remaining flow control window of 350. What should an implementation do ? 1) send a frame composed of: pad_low + 100 bytes of data + 249 bytes of padding 2) send a frame composed of: pad_high + pad_low + 48 bytes of data + 300 bytes of padding D) What if the remaining flow control window is exactly 300 (or 302 in case A2 holds true) ? 1) send a frame composed of: pad_low + 100 bytes of data + 199 bytes of padding 2) do not send a frame because there is enough space for padding but not for data ? E) An application wants to write 20 MiB of data with a padding of 300 bytes. Does this mean: 1) N data frame frames without padding, and a last frame with the remainder of the data and 300 bytes of padding 2) N data frames each with 300 bytes of padding. Are there security implications for case D2 (an intermediary could stall a frame by carefully choosing window updates) and E2 (if the padding is a constant, is its role useful) ? Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
Received on Thursday, 12 June 2014 17:29:38 UTC