search

braid-org / braid-spec

Working area for Braid extensions to HTTP
https://braid.org
235 stars 16 forks source link

Allow servers to advertise that they support Subscribe #54

Open toomim opened 5 years ago

toomim commented 5 years ago

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 that those are for media types and method names, respectively. Do we know of a header name that would be appropriate to say that a server supports subscriptions? Maybe just a special header like Allow-Subscriptions?

@mitar @brynbellomy I'm wondering if you guys have seen anything like this before. This could also be supported in an OPTIONS request like Bryn wrote for the range patch spec.

brynbellomy commented 5 years ago

Hmm, good question. I guess I'm still a little inclined to lean on OPTIONS for negotiating capabilities. It fit nicely for range patches. We end up with 1 extra request in the case of the Chrome extension's initial page load, but in most other cases it'd require the same number to do OPTIONS -> GET with Subscribe as it would to do GET -> GET with Subscribe.

On Tue, Nov 12, 2019 at 1:18 AM Michael Toomim notifications@github.com wrote:

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 that those are for media types and method names, respectively. Do we know of a header name that would be appropriate to say that a server supports subscriptions? Maybe just a special header like Allow-Subscriptions?

@mitar https://github.com/mitar @brynbellomy https://github.com/brynbellomy I'm wondering if you guys have seen anything like this before.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/braid-work/braid-spec/issues/54?email_source=notifications&email_token=AABBBE4JJ4NCOIBVIRSD2CTQTJKD7A5CNFSM4JL7JRB2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HYTQSWQ, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABBBEZ5FTYYVQB5GTOFZHDQTJKD7ANCNFSM4JL7JRBQ .

toomim commented 5 years ago

Yeah, OPTIONS would be nice. A key question is what header is used to advertise the capabilities?

We could re-use the Subscribe: header. If a server supports subscriptions at a resource, but they aren't currently enabled, it could report Subscribe: available. If they are enabled, it could report Subscribe or Subscribe: keep-alive=N.

This would mean that in the OPTIONS request, it would probably always return Subscribe: available.

alficles commented 4 years ago

That makes the Subscribe header both request and response. I'm not sure that makes it all that much clearer.

toomim commented 4 years ago

The spec already includes a Subscribe header for responses, to let the client know whether the server is willing to keep the subscription alive, and store enough history to be able to synchronize with the client if/when it comes back online at a later date.

At this point, it seems to me that the solution is to add this Subscribe header to Options.

alficles commented 4 years ago

Ah, right. That makes sense. OPTIONS is probably the right option here. A server that handles CORS will already be adding the relevant headers to the Access-Control-Allow-Header option there as well.

mitar commented 2 years ago

I suggest that Subscribe should include maybe also the version of the protocol or subscription support. Or maybe list support for different transport protocols if we ever want to support them (websockets vs. server-side events)?

The main thing I am trying to say is that available seems to be very low information and maybe v1 could be better. Just to be future safe.