<commit_before>Simplish HTTP Push Relay Protocol, Rev. 2

1. Introduction
1.1 Purpose
The primary purpose of this protocol is to enable a method of long-polling, 
transparent to the web client, where client connections idle only on the HTTP 
server and need not be forwarded.

1.2. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 
interpreted as described in RFC2119. An implementation is not compliant if it 
fails to satisfy one or more of the MUST or REQUIRED level requirements for 
the protocols it implements. An implementation that satisfies all the MUST or 
REQUIRED level and all the SHOULD level requirements for its protocols is 
said to be "unconditionally compliant"; one that satisfies all the MUST level 
requirements but not all the SHOULD level requirements for its protocols is 
said to be "conditionally compliant."

1.3. Terminology
This specification uses a number of terms to refer to the roles played by 
participants in, and objects of, this protocol:
  server
    The HTTP server implementing this protocol.
  client
    A program that initiates TCP/IP connections with the HTTP server for the 
    purpose of sending HTTP requests.
  listener
    A client that sends HTTP requests, which it expects could be long-held, 
    for the purposes of receiving some message when it becomes available. A 
    listener receives at most one message per request.
  sender
    A client that notifies the server of the availability of messages for some
    listener.
  message
    Application specific data that is relayed from a sender to a receiver.
  channel
    An isolated channel of communication between some senders and some 
    listeners privy to its existence. 
  channel id
    A unique identifier for a channel.
  location
    A url (or set of urls) on the server.
    
2. Requirements
2.1 Server Requirements
The HTTP server MUST have a mechanism of specifying a url, or a set of urls as
sender and receiver locations. All connections to the sender location MUST be
treated as senders, all to the receiver location as receivers.
Furthermore, the server MUST implement a mechanism for identifying each sender
and receiver request with an id. This MAY, for example, be a url parameter 
(/foo/?id=123) or a cookie (although methods of channel identification other 
than those using the url are inadvisable).
The server MUST accept requests on sender locations and respond to them 
immediately. It MUST also accept requests on listener locations, but need not 
respond immediately.

2.2 Client Requirements
All client HTTP requests must be valid. Listener clients must have a caching 
mechanism that appropriately reacts to Last-Modified and Etag response headers 
(web browsers, for example).

2.2 The Channel ID
It is not the responsibility of the server to generate IDs.

4 Server Operation
A sender request functions as notification to the server of a message to send 
to a listener over some channel. A listener request notifies the server of the 
listener's intent to receive a message.

4.1 The Listener
The server MUST accept all valid HTTP requests to the listener location.
The server, when sent a listener request, MUST satisfy all of the following
conditions:
  - GET requests with no If-Modified-Since header will be responded to with the
    oldest available message in the channel, or will be long-held.
  - GET requests with an If-Modified-Since header will be responded to with 
    the next message in the channel (as identified by the cache information 
    headers), or will be long-held. The If-None-Match header may also be used.
  - A GET request that is being long-held MUST be responded to with EITHER:
     - 200 OK when a message is received. The Content-Type header MUST be set
       to the same header of the original sender request. 
     - 410 Gone if the channel becomes unavailable (i.e. has been deleted).
     - 409 Conflict if another listener has conflicted with this request.
     - 403 Forbidden
  - All other request methods SHOULD be responded to with a 405 Method Not 
    Allowed status.
In addition, the server MUST do one of the following when sent a valid listener
GET request:
 - All other long-held listener requests will be send a 409 Conflict response.
   (last-in-first-out)
 - All but the oldest (including this) request will be sent a 409 Conflict
   response. (first-in-last-out)
 - No additional actions are performed. (broadcast)
The server SHOULD make this selection configurable.

4.2 The Sender
The server MUST accept all valid HTTP requests to the sender location.
The server, when sent a sender request, MUST satisfy all of the following
conditions:
  - GET requests receive a 200 OK response for known channels and a 
    404 Not Found otherwise.
  - PUT requests receive a 200 OK response. The request creates a channel if 
    no channel with the given channel id exists.
  - DELETE requests receive a 200 OK if the channel identified by the 
    channel id exists and has been completely deleted. All listeners MUST 
    have been sent a 410 Gone response. Requests for nonexistent channels MUST
    be responded to with a 404 Not Found.
  - POST requests are used to send messages. The request MAY contain a body in
    any encoding representing a message to be sent over the channel. The message
    MUST be immediately delivered to all currently long-held listener requests.
    Additionally, the message MAY be stored for future retrieval and the oldest<commit_msg>fixed incorrect section numbering<commit_after>Simplish HTTP Push Relay Protocol, Rev. 2.1

1. Introduction
1.1 Purpose
The primary purpose of this protocol is to enable a method of long-polling, 
transparent to the web client, where client connections idle only on the HTTP 
server and need not be forwarded.

1.2. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 
interpreted as described in RFC2119. An implementation is not compliant if it 
fails to satisfy one or more of the MUST or REQUIRED level requirements for 
the protocols it implements. An implementation that satisfies all the MUST or 
REQUIRED level and all the SHOULD level requirements for its protocols is 
said to be "unconditionally compliant"; one that satisfies all the MUST level 
requirements but not all the SHOULD level requirements for its protocols is 
said to be "conditionally compliant."

1.3. Terminology
This specification uses a number of terms to refer to the roles played by 
participants in, and objects of, this protocol:
  server
    The HTTP server implementing this protocol.
  client
    A program that initiates TCP/IP connections with the HTTP server for the 
    purpose of sending HTTP requests.
  listener
    A client that sends HTTP requests, which it expects could be long-held, 
    for the purposes of receiving some message when it becomes available. A 
    listener receives at most one message per request.
  sender
    A client that notifies the server of the availability of messages for some
    listener.
  message
    Application specific data that is relayed from a sender to a receiver.
  channel
    An isolated channel of communication between some senders and some 
    listeners privy to its existence. 
  channel id
    A unique identifier for a channel.
  location
    A url (or set of urls) on the server.
    
2. Requirements
2.1 Server Requirements
The HTTP server MUST have a mechanism of specifying a url, or a set of urls as
sender and receiver locations. All connections to the sender location MUST be
treated as senders, all to the receiver location as receivers.
Furthermore, the server MUST implement a mechanism for identifying each sender
and receiver request with an id. This MAY, for example, be a url parameter 
(/foo/?id=123) or a cookie (although methods of channel identification other 
than those using the url are inadvisable).
The server MUST accept requests on sender locations and respond to them 
immediately. It MUST also accept requests on listener locations, but need not 
respond immediately.

2.2 Client Requirements
All client HTTP requests must be valid. Listener clients must have a caching 
mechanism that appropriately reacts to Last-Modified and Etag response headers 
(web browsers, for example).

2.2 The Channel ID
It is not the responsibility of the server to generate IDs.

3 Server Operation
A sender request functions as notification to the server of a message to send 
to a listener over some channel. A listener request notifies the server of the 
listener's intent to receive a message.

3.1 The Listener
The server MUST accept all valid HTTP requests to the listener location.
The server, when sent a listener request, MUST satisfy all of the following
conditions:
  - GET requests with no If-Modified-Since header will be responded to with the
    oldest available message in the channel, or will be long-held.
  - GET requests with an If-Modified-Since header will be responded to with 
    the next message in the channel (as identified by the cache information 
    headers), or will be long-held. The If-None-Match header may also be used.
  - A GET request that is being long-held MUST be responded to with EITHER:
     - 200 OK when a message is received. The Content-Type header MUST be set
       to the same header of the original sender request. 
     - 410 Gone if the channel becomes unavailable (i.e. has been deleted).
     - 409 Conflict if another listener has conflicted with this request.
     - 403 Forbidden
  - All other request methods SHOULD be responded to with a 405 Method Not 
    Allowed status.
In addition, the server MUST do one of the following when sent a valid listener
GET request:
 - All other long-held listener requests will be send a 409 Conflict response.
   (last-in-first-out)
 - All but the oldest (including this) request will be sent a 409 Conflict
   response. (first-in-last-out)
 - No additional actions are performed. (broadcast)
The server SHOULD make this selection configurable.

3.2 The Sender
The server MUST accept all valid HTTP requests to the sender location.
The server, when sent a sender request, MUST satisfy all of the following
conditions:
  - GET requests receive a 200 OK response for known channels and a 
    404 Not Found otherwise.
  - PUT requests receive a 200 OK response. The request creates a channel if 
    no channel with the given channel id exists.
  - DELETE requests receive a 200 OK if the channel identified by the 
    channel id exists and has been completely deleted. All listeners MUST 
    have been sent a 410 Gone response. Requests for nonexistent channels MUST
    be responded to with a 404 Not Found.
  - POST requests are used to send messages. The request MAY contain a body in
    any encoding representing a message to be sent over the channel. The message
    MUST be immediately delivered to all currently long-held listener requests.
    Additionally, the message MAY be stored for future retrieval and the oldest
{'fraction_non_alphanumeric': 0.033714898944732605, 'fraction_numerical': 0.011894115542836701, 'mean_word_length': 3.7007145859604877, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '449263', 'n_tokens_mistral': 2901, 'n_tokens_neox': 2654, 'n_words': 1720}