- From: Kazuho Oku <kazuhooku@gmail.com>
- Date: Mon, 15 Jul 2019 21:35:02 +0900
- To: "Roy T. Fielding" <fielding@gbiv.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Roy, thank you for your comments. My responses inline. 2019年7月13日(土) 3:54 Roy T. Fielding <fielding@gbiv.com>: > > On Jul 12, 2019, at 7:01 AM, Kazuho Oku <kazuhooku@gmail.com> wrote: > > Hello all, > > Thank you very much for all the discussion here and elsewhere. > > Based on the feedback, Robin, Lucas and I have expanded the number of urgency levels from 3 to 8, including a "background" level. From what we have heard, this would be sufficient; 5 levels is what some browsers use now (and we now provide 5 + background to them). > > I hope that this gives them enough space to start with (we can subdivide existing levels later), at the same time associating enough meanings to each of the urgency levels so that the servers can tweak the prioritization scheme. > > We can't submit -01 now, but the up-to-date draft can be found at: > > https://kazuho.github.io/draft-kazuho-httpbis-priority/draft-kazuho-httpbis-priority.html > > The repository and the issue list can be tracked from https://github.com/kazuho/draft-kazuho-httpbis-priority/. > > Please let us know what you think. Thank you in advance. > > > Hi Kazuho, > > This is starting to sound a lot like Waka's request priority (hi, lo, HiLo) and request context > [slide 9 of http://tools.ietf.org/agenda/83/slides/slides-83-httpbis-5.pdf ]. I agree that defining > this as an e2e header field is a good way forward. HiLo is progressive with high priority for the > first block and then regular priority for the rest. Thank you for sharing the slides. It's reassuring to know that you had thought about something similar, and still think that it's preferable. HiLo is interesting. Am I correct in assuming that the intended primary use case is to transmit the size of the images so that the browsers can determine the layout at an earlier moment? While I think that such signal is useful to some extent, I am not sure how useful it is. Partly because it is not the best way of notifying the client the metadata at the earliest moment. In case of images, we typically embed the size of the image either in the CSS or the IMG tag, so that the client would not need to wait for the first few bytes of the image. The other reason is that HiLo does not communicate the reason the client thinks the first few bytes are important. If we are to have something like HiLo, I think it would be better to have a richer signal that tells the server why and / or what needs to be sent ASAP. Considering these aspects and the fact that the H2 prioritization does not have this type of signal, I think we can start without having HiLo in the Priority header. > Note that there are other (security and privacy) reasons for explicitly communicating the context > of a request, since it can be used to detect some forms of fraud, phish, or transclusion. > However, that would need to be in a non-script-settable field. I agree that such filtering rule would help us to some extent. Though it would be fragile regardless of the header field defined as non-script-settable, considering the fact that clients that do not implement the Priority header extension could pass through the header field set by the application. > We should also consider non-browsing priorities, such as indicating intentionally long-lived > responses that might have a low priority but do require some form of unbuffered regularity > (e.g., pongs). I'd argue that one of the non-background urgencies should be used for a request that require a timely response (e.g., ping-pong). Maybe the issue in the current draft is that, as others have pointed out, the terms "non-background" urgencies are too browser-centric. It might be a good idea to consider renaming "document" to "default" at least. > I don't think progressive is an independent parameter unless we intend > to communicate some sort of block size; otherwise, it is just saying that HoL blocking > isn't desired, which is not necessary to communicate beyond not setting "background". I'd argue that the progressive parameter is not related to HoL blocking. It's rather a way to signal if the user experience would improve by interleaving the response with others. The intended use-case is for images that support progressive rendering, as IIUC generally assumed that interleaving between the responses that carry images that can be rendered progressively improves user experience. > > In general, I like the approach, but I think the structured header syntax is the wrong choice. > Why send 26 bytes to communicate one (or maybe two) bytes of information? Honestly speaking I wouldn't mind choosing something else than Structured Headers as long as the alternative is extensible. At the same time, I do not think 26 bytes is an issue because I'd assume that it would be compressed into just a few bytes with HPACK / QPACK. > > ....Roy > -- Kazuho Oku
Received on Monday, 15 July 2019 12:35:39 UTC