Re: Benjamin Carlyle http 2.0 expression of interest

On Jul 23, 2012 7:30 AM, "Amos Jeffries" <squid3@treenet.co.nz> wrote:
>> > #5 A must understand model
>> > Currently if a new feature is added to http requests that must be
understood servers the client must use a new http method to ensure that a
server who does not understand will reject the request. Perhaps it is time
to introduce a more refined model. My thinking is a must understand header
that consists of tokens/urls stating special requirements the server must
fulfil before accepting the message for processing. The client could
include an additional header that indicates its own supported features to
allow the server to tailor its own processing or potentially reject the
request.
>
> This was tried with Expect. It broke rollout of new features in a lot of
areas. Software lifetimes at the deeper levels of the network is measured
in cycles of 5-10 years. They simply wont be able to keep up with new
header/feature additions. At present they can at least pass-thru by default.

I agree that the hop by hop nature of the Expect header is not useful. I
was looking more towards an end to end model. For example, say a client
wants its server to only execute a transaction if it promises to check a
given precondition first. If the precondition is not understood and is
ignored the client will be in dire straits due to the action being executed
when it should not have been. This seems to me the main useful use cases
for a must understand semantic.

>> > #6 An idempotent POST
>> > It would be helpful to have a way to idempotently POST new state. My
preference would be for the client to be able to supply a unique identifier
as part of its request that can be used by the server to ignore repeated
instances of the message, preferably as a uuid or guid in uri form or other
unique uris.
>> This would require an API change for browsers if this was exposed to
webapp designers as well.
>
> How does this differ from GET with query string and entity?
> The base portion of the URL is the processor script/app address and the
query portion of the URL is a UUID within that particular URI processor
space. Together they form a GUID.
>
> In order to be idempotent the URI alone must be able to be used by caches
to produce a correct response without the entity being even received.
>
> When you have a client implementation that is tied so closely together
with the server that it can identify what UUID generation algorithm the
server will be using AND the data points the server will use to generate
it. You can make any request idempotent with ETag and If-* conditionals.
>
>
>   POST /foo HTTP/1.1
>   If-None-Match: "something"
>   ETag: "something"

Yes, all I'm really looking your in this one is the one true way to do it
that eventually all clients will support ("I'll supply this extra header
because it's cheap to do so and usually helpful") and most servers will
implement ("I'll attach the client provided id to the created state for an
appropriate amount of time but otherwise handle it opaquely. I'll use it to
convert future POST requests with the same id into PUT requests over the
already-created state") where security considerations are considered
(clients can't steal each other's ids or force a POST to be misinterpreted).

There are many techniques out there, but not many that can complete in a
single request and not many that are independent of the specific server's
decision about how to structure its uri space. It would be nice to draw a
line under such a common use case.