- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Wed, 18 Jul 2012 21:03:51 +0000
- To: James M Snell <jasnell@gmail.com>
- cc: ietf-http-wg@w3.org
In message <CABP7RbfFj__CeriiJA-caEda_h0K5b__oj6-zYRuA=BgSofuhA@mail.gmail.com> , James M Snell writes: >2. Just for the sake of clarity, what is the expected behavior if a >user-agent interleaves multiple modification requests to the same resource? >For instance: > > => SYN_STREAM(id=1,:method=PUT,:path=/my/resource) > => SYN_STREAM(id=2,:method=DELETE,:path=/my/resource) > => SYN_STREAM(id=3,:method=POST, :path=/my/resource) This is entirely parallel to the same issue with respect to tagged-queueing of requests to a disk drive and remote filesystem operations. You basically have three choices: 1. Make it automatic. Any non-idempotent operation is a synchronizing/stalling event that prevents reordering of other operations across it. The following request stream will always execute seqentially in this case: => SYN_STREAM(id=1,:method=GET,:path=/my/resource) => SYN_STREAM(id=2,:method=PUT,:path=/my/resource) => SYN_STREAM(id=3,:method=GET,:path=/my/resource) => SYN_STREAM(id=4,:method=DELETE,:path=/my/resource) => SYN_STREAM(id=5,:method=GET,:path=/my/resource) => SYN_STREAM(id=6,:method=POST, :path=/my/resource) => SYN_STREAM(id=7,:method=GET,:path=/my/resource) 2. Give the requestor a synchronizing primitive. Basically allowing the client to say "don't reorder anything across this marker, but continue to optimize on both sides" The following request stream will always execute seqentially in this case: => SYN_STREAM(id=1,:method=GET,:path=/my/resource1) => SYN_STREAM(id=2,:method=GET,:path=/my/resource2; sync=yes) => SYN_STREAM(id=3,:method=GET,:path=/my/resource1) (Notice that you can sync on an indempotent operation, this is deliberate, as it allows "cheap" NOP-sync operations.) 3. Leave the behaviour undefined. It's anyones guess what will happen. In a web where client-side is non-participating in application logic (ie: the good old fill-the-form-press-submit model), any of these will do. But we are increasingly seeing web-apps that actively participate in, and have deep knowledge of the application logic on the server side. For those, number one is the safe choice, but it pessimizes needlessly and number three will cost RTT's because the client has to wait for operations to complete before issuing dependent operations. That leaves the second option, and given the cheapness of implemenation (You tag all requests with a generation number which increases after every sync-tag, never sort higher generation before lower.) I think that is the most future-proof choice for HTTP/2.0. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Received on Wednesday, 18 July 2012 21:04:15 UTC