"Render"

[mnot@…]

3.4 Handling Incomplete Messages -- "A user agent MUST NOT render..." should be "A user agent MUST NOT consider..."

[mnot@…]

In Atlanta:

kevin falk: are you prohibited from using particular code blocks to users?

rf: the important consideration is that the user is able to learn that the information is incomplete

julian r: that is getting ignored in practice

brian smith: we (Mozilla) ignore this requirement, pages are already displayed

mnot: would it be OK to show status in the web console?

rf: not really

bs: there are UX considerations that make this more difficult than it would appear

bs: there's not much difference between XHR and the render as HTTP clients

jr: we could add an indicator

ted hardie: visual indicators are not necessarily universally applicable

rpeon: there is a lot of confusion stemming from this statement, prefer the parenthetical

bsmith: no idea about how XHR works, though it does have streaming modes; script developers are important

will chan: chrome ux people didn't like the idea of having something in chrome

rf: this is a safety/security feature

kfalk: incomplete !== error

julian: there is a related issue about truncated *downloads* (as in "save as"); Eric Lawrence once blogged about it (<​http://blogs.msdn.com/b/ieinternals/archive/2011/03/09/browsers-accommodate-incorrect-http-content-length-and-sites-depressingly-depend-on-it.aspx>)

pmcm: rathole, we (Moz) do very little prescribed error handling and it's strange spending time on this when there are many others; tried to rollback rendering when MD5 sum failed, got immense push back

mnot: maybe this should be prose

ACTION: Roy to make this prose text in the security considerations

[fielding@…]

From [2033]:

Move new user agent requirement on rendering incomplete responses to a suggestion in security considerations. Addresses #408 and #415

Consolidate more stuff on persistent connection reuse. Addresses #396