Open michielbdejong opened 10 months ago
Ah, that's an interesting distinction to draw attention to!
Perhaps we should say more clearly that "a client can ignore the update, and a server can reject it." I wonder what status code the server should respond with?
We also have longer-term plans to extend HTTP to allow clients to send acknowledgements back to servers. This might help with what you're doing.
Note that this work is in Level 3 of the Protocol Roadmap— it requires moving HTTP beyond a request/response client/server architecture, and generalizing it into a P2P messaging system. (I presented on this in Braid Meeting 2. Here's a shortcut to the video explaining the relevant slides 12-15.)
So whereas today's HTTP lets a client mutate a server (with acknowledgement):
Client request:
PUT /foo # "The state of /foo is now X
X
Server response:
HTTP/1.1 200 OK # Acknowledge
...
And lets a server mutate a client (without acknowledgement):
Client request:
GET /foo
...
Server response:
HTTP/1.1 200 OK # "The state of /foo is now X"
X
# ...client cannot acknowledge :(
We could generalize HTTP into a more symmetric, P2P future, like this:
Peer A:
GET /foo
Subscribe # Peer A asks to know about /foo from B
Peer B:
GET /foo
Subscribe # Peer B asks to know about /foo from A
Peer A:
PUT /foo # "The state of /foo is now X"
Version: "1"
X
Peer B:
ACK /foo # HTTP/1.1 200 OK
Version: "1"
seen: local # Everyone in phase 1 commit has seen this
valid: local # All validators in phase 1 commit has validated this
Peer A:
ACK /foo # HTTP/1.1 200 OK
Version: "1"
seen: global # Everyone in phase 2 commit has seen this
valid: global # All validators in phase 2 commit has validated this
This can generalize the 200 OK
message into a full 2-phase commit cycle. The cycle can tell you both whether a mutation has been validated (e.g. accepted by various authoritative servers) and whether it's been seen by all peers on the network.
I think this might help with what you're doing. Nobody has proposed a spec for it yet, but a compelling application could give us a reason to spec it up.
The idea of reversing the roles of clients and servers was also brought up this fall at IETF 118 in @bemasc's Reverse HTTP proposal (slides).
Austin Wright (@awwright) pointed out in that session that it's actually possible to do this today on HTTP, even though people don't. It wouldn't be supported in the browser fetch()
API IIRC, but if your code only goes server-to-server, I think it would work.
I have a question;
So IIUC "ignore" applies to recipients that are http clients, and "reject" refers to recipients that are http servers?
Is this because the http server can send back a http status code but a client cannot?