Difference between ignoring and rejecting an update

[michielbdejong]

I have a question;

If a client or server does not specify a Parents header when
transferring a new version, the recipient MAY presume that the most
recent versions it has (the frontier of time) are the parents of the
new version. It MAY also ignore or reject the update.

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?

[toomim]

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?

[toomim]

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.

[toomim]

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.