Re: p1 7.2.4: retrying requests

On 06/04/2011 06:06 PM, Mark Nottingham wrote:
> However, we could make it clear that it's OK for clients to retry non-idempotent requests when they have some sort of agreement (in-band, e.g., a protocol extension like POE, or out-of-band).
> Would that be workable for you?

These cases may be easier to think about in comparison if we think of 
click-wrap (licenses) to cover the chunked-mode with Expect/continue. 
Instead of some cookie that is stored in the headers if someone has seen 
the click-wrap or not, the Expect/continue could be used instead. 
Browsers can take action and prompt "Abort, Retry or Fail?" or would 
need implementation of "remember this choice" checkbox for like conditions.

In 7.2.4, "the client SHOULD retry the request" may indicate the 
connection closed due to timeout of the click-wrap condition. When the 
user responds to the prompt, the request "SHOULD" retry with appropriate 
remembered action on the condition.

That can help in cases where licensed media is aggressively searched for 
more content (and action links) before the condition is satisfied, or 
determine if licensed media is new to some device despite whatever the 
user response.

That is some sort of agreement, yet I also wondered if these conditions 
helps prevent or detect double-click and know redundant actions. For 
example, request on key-down, continue on key-up, and complete response 
with action.

"Drop 7.2.4...?" Yesterday, I thought over the HTML5 canvas again for 
rasterized images and where the UI is on that canvas, the window 
instance is on the proxy (inner-browser), and the client-browser only 
manages tabs (outer-browser). I wouldn't want to discourage that 
ability, as I know of businesses that rather keep their keep their 
analog assets private and just render digital versions of them for 
licensed proxies.

The common conflict exists where that is prevented with monolithic 
design, all-in-one.

--- ---
Web Development, Software Engineering, Virtual Reality, Consultant

Received on Sunday, 5 June 2011 16:02:17 UTC