HTTP Subscription is important in real-time distributed environments. HTTP has no native subscription mechanism. Content that changes at a constant rate can be retrieved at this rate. Content that changes at a varying rate must be polled. Polling is making requests on a periodic basis without any notification from the server to indiate a change has taken place. Polling schemes may be too slow and delay change being detected or too fast, and waste bandwidth and processing resources. Polling can be tuned by increasing the poll rate for recently-changed URIs, however all polling-based mechanisms are limited in some way. I propose a HTTP subscription mechanism to avoid polling by allowing notification from a server when changes occur.    (5EX)

Different approaches may suit different use cases. I've been working on a few different approaches to come up with an overall strategy and haven't yet achieved what I would call an ideal solution. HttpSubscriptionSpecification describes my first attempt to make things work. It effectively tries to standardise subscription to a single resource by using a single retained TCP/IP connection. Multiple subscriptions require multiple connections, and at sufficient scale this appears to be a showstopper. My second approach is to work back from the GENA protocol with HttpSubscriptionGENA. Here I try to soften and reinforce the GENA protocol in ways I consider necessary to develop an adequate protocol model. Unfortunately here there are also problems. GENA (and its variants) require a web server to be running on a client machine and accessable to the event source. This is what I was originally trying to avoid, but I've taken some heart from RTSP that has similar constraints on it. In that protocol firewalls are required to analyse SETUP requests to find and use Transport headers. Firewalls may open up the specified ports to allow outside connections for these limited purposes. I have now begun to see the issue of opening up firewall ports for various reasons as being outside the scope of this specification and something that needs to be resolved through distinct IETF channels.    (5IT)

If using a small number of TCP/IP connections is required to make use of a large number of subscriptions without the ability to listen I've revied the HttpResourceAggregation concept. This time, instead of defining an aggregate resource that can be subscribe to I'm defining a subscribable channel which can have HttpSubscriptionGENA notifications routed to it. This may be of some use and value.    (5K5)

  1. HttpSubscriptionRequirements    (5EY)
  2. HttpSubscriptionSpecification (retained connection)    (5EZ)
  3. HttpSubscriptionGENA (open listening port)    (5IS)
  4. HttpResourceAggregation (route GENA notifications to a long-reponse notification channel)    (5GA)
  5. HttpSubscriptionImplementationExperience    (5IG)

Some prior and related art exists for this kind of subscription (feel free to add more):    (5G6)

Requirements    (5IN)

Theory    (5K0)

Blog    (5ME)

Specifications    (5IP)

Implementations    (5IQ)

Please note: I have included room at the bottom of the requirements and specification pages for comments. Please include your input there. Please contact BenjaminCarlyle before changing any other part of the documentation.    (5G9)