Michael Toomim
Michael Toomim
Our current implementations (both `braidify` and `braid-protocol`) both set the `cache-control: no-cache, no-transform` header, but it looks like this is no longer in the spec. It looks like it used...
In existing HTTP, if a resource doesn't exist, the server responds with a `404 not found` and ends the connection. A resource that exists can be deleted with the `DELETE`...
If a client does: 1. `GET` /foo subscribe 2. `PUT` /foo "hello" Then a naive server might send the client's PUT (2) back to it, because it subscribed in (1)....
It'd be nice for a server to advertise that it lets you Subscribe to a resource. I'm thinking it could send in its response something like `Accepts:` or `Allow:`, except...
I noticed that the example HTTP responses have a `Patches: OK` header, but these aren't actually discussed in the spec. What are these for? We should either explain them, or...
The headers we specify on patches currently have the `Content-` prefix: ``` Request: PUT /chat Content-Type: application/json Patches: 2 Content-Length: 53
With the JSON Range Unit, the deletion of a field on a JSON object (e.g. `delete foo.bar`) is currently ambiguous: ``` A patch with empty contents corresponds to deletion of...
I'm concerned that the PUT request could be incorrectly cached by intermediaries that don't understand the Braid extensions. For instance, if we send a PUT with a patch, might a...
In order to prevent existing caches from trying to cache a patch, the current spec requires a patch to specify `Cache-Control: no-cache, patch`. However, I just discovered that the same...
I'd be happy to buy one for you, if it would help development on this project!