Basic HTTP push relay Protocol

Original English:

Https://pushmodule.slact.net/protocol.html

Simple HTTP push Protocol
1 Introduction
1.1 Purpose
The original intention of this Protocol is to provide support for transparent and persistent connections of the HTTP client. The connection on the server is idle for most of the time and will not be retransmitted.
 
1.2 General description
Omitted

1.3 terms
This specification uses a series of terms to refer to objects encountered in the agreement.
Server)
The HTTP server that implements this protocol.
Client)
A program that can initiate a TCP/IP connection to the HTTP server.
Message)
Data of a specific application is usually contained in the request or reply body.
Channel)
Indicates the path resource of a message. Each channel has a separate message queue.
Subscriber)
A client that sends an HTTP request to the server and wants to receive the message on a channel.
Publisher (publisher)
One sends an HTTP request to the server and wants to send its information to the subscriber through a channel.
Channel ID)
A special string that identifies a channel.
Location)
A URL of the server.

2. Requirements
2.1 server requirements
The HTTP server must be able to set the publishing and subscription locations through URLs. All requests sent to the publishing location must be considered a publisher's request. All requests sent to the subscription location are considered as subscriber requests.
The server must be able to recognize different channels with specific characters. For example, it can be a URL parameter (/Foo /? Id = 123) or a cookie. You can also use other methods to differentiate channels, but it is strongly not recommended.
The server must receive a request sent to the publishing location and reply quickly. Of course, you must also receive requests sent to the subscription location, but do not need to reply immediately.

2.2 client requirements
All clients must generate valid HTTP requests. Subscription clients (such as browsers) must have a caching mechanism for last-modified and etag.

2.3 channel ID
The server is not responsible for generating channels, but rather the client.

3. server operations
A publisher's request is like a notification. messages are sent to the subscriber through a channel. The subscriber's request is to inform the Server Client that it is ready to accept the message.
3.1 subscribers
The server must receive all http get requests sent to the publishing location. The HTTP request of other methods should respond to the 405 status (method not allowed ).
A subscriber's request is considered to be a message subscription notification. A subscriber can request an existing, invalid, or invalid request. The subscriber uses if-modified-since and if-None-match to differentiate these messages. If the client does not have the IF-modified-Since Header, it must be assumed that the client is requesting the oldest message in the channel. Each 200 (OK) reply message must contain the last-modified and etag headers, so that the subscriber can obtain the next message through these headers. In addition, 200 (OK) must include the Content-Type header of the message publisher, unless the publisher does not specify the content-type or the server configuration deliberately wants to hide the Content-Type.

HTTP servers generally have multiple pushing mechanisms. The server's response to a subscriber's request should be configurable and must be listed below:
Long-Polling (long-polling)
Response will be made to existing messages quickly. If a request is not yet valid, it must be delayed until the message becomes valid. Delayed responses must meet all of the following conditions:
+ When a message is valid, a 200 (OK) reply containing the message and content-type must be sent immediately. This reply should be no different from those that reply immediately.
+ If the channel that the subscriber waits for is deleted or becomes invalid for some reason, the server must immediately send a 410 (gone) reply.
+ If the request of another subscriber conflicts with the request. The server must immediately respond to conflict ).
Interval-polling)
All requests must be responded immediately. If no valid message exists, the server must immediately respond to 304 (not modified ).

In addition, when the server accepts more than one subscriber on the same channel, it must perform the following actions:
Broadcast (broadcast)
No other behavior.
Last-in, first-out)
In addition to the recently waited subscriber, the other subscriber is responded to 409 (conflict ).
First-in, last-out)
In addition to the longest-waiting subscriber, the subscriber responds to 409 (conflict) to other subscriber ).

The server must be able to configure these behaviors and broadcast by default.

3.2 publisher
The server must accept all valid HTTP requests sent to the publishing location. Different servers requested by the publisher must meet the following conditions:
* GET request: If this channel machine exists, the system returns the 200 (OK) message; otherwise, the system returns the 404 (not found) message ).
* Put request: directly replies to 200 (OK). If the channel does not exist, a channel is created based on the channel ID.
* Delete request: If a channel exists, the system replies to "200 (OK)" and deletes the channel. All subscribers of this channel will receive a 410 (gone) reply. If it does not exist, return 404 (not found ).
* POST requests are used to send messages. A message is contained in the request body and can be sent through a channel using any encoding. Messages must be sent immediately to those subscribers who are waiting for a long time. In addition, messages can be saved for future use. The oldest message can also be deleted. If a POST request sends this message to the subscriber, the server must respond to the 201 (created) request ). If not, the system returns 202 (accepted ). The Content-Type Header must be forwarded along with the message.
The message retention limit parameter should be configurable. The publisher location should be configurable. All replies to the publisher 200 must contain the channel information of the application. This information may contain the number of stored messages and the number of subscribers waiting for a long time. For this information, the server may realize some negotiation.