What is jsontp?

jsontp is a new standard, aimed to increase interoperability with existing standards across the web, rather than relying on the unique nature of HTTP.
it uses TCP as the transport layer, and JSON as the data format, which is already widely used across the web.

Why jsontp?

jsontp is designed to be a more efficient and reliable way to transfer data across the web. It's standard is stricter than HTTP, and it's designed to be very similar if not the same across all platforms.
the standard, while written in formal English, is not written in a way that is difficult to understand. It's designed to be easy to understand and implement.

Core concepts

there are two main concepts in jsontp: the request and the response. The request is the data that is sent to the server, and the response is the data that is sent back to the client.
the request and response are both JSON objects, and they are both sent over TCP.
they are both sent in a specific format, which is defined in the jsontp standard, and explained later in this book.

Types of Messages

In this section, we will discuss the different types of Messages that can be made to the JSONTP server.
There are two main types - request and response.

Request

the request message is sent from the client to the server
it is a JSON object, and follows a specific format, which is discussed line by line below

Request Format

{
    "jsontp": "1.0",
    "type": "request",
    "resource": "/path/to/resource",
    "method": "GET",

    "headers": { 
        "key1": "value1",
    },

    "body": {
        "key1": "value1", 

        "content": "raw text to be sent",

        "encoding": "gzip"
    }
}

Fields

if a required field is not present, the server will respond with a 400 Bad Request status code
if a field is provided that is not in the list below, the server will respond with a 400 Bad Request status code
if a field is in an incorrect format, or is an incorrect type, the server will respond with a 400 Bad Request status code

`jsontp` - `string`, required

the version of the jsontp standard that the message follows
it is always in the form major.minor(-rcx), where x is the release candidate number
for example, 1.0, 1.1, 1.2-rc1, etc.

`type` - `string`, required

the type of message, which in this case is request.

`resource` - `string`, required

the path to the resource that the client is requesting
below are some examples of valid resource fields:
- /
- /index.html
- example.com/index.html
- example.com:8080/index.html
- example.com:8080/route?query=string
- example.com:8080/route?query=string#fragment
- path/to/resource
- jsontp://example.com:8080/path/to/resource
different servers may handle this differently, so it is ideal to send requests in the first or second format, which is / followed if necessary by the path to the resource

`method` - `string`, required

the method to use when making the request
below are the list of HTTP methods mentioned in the standard:
- GET
- POST
- PUT
- DELETE
- OPTIONS
bear in mind that the server may not support all of these methods, as it only is required to support GET and POST. If the server does not support the method, it will respond with a 405 Method Not Allowed status code

`headers` - `object`, required

the headers to send with the request
the keys are the header names, and the values are the header values
in the request there are no required headers
below are some examples of valid headers fields:
- {}
- {"key1": "value1"}
- {"key1": "value1", "key2": "value2"}
all header keys are case-insensitive, so the server will treat Content-Type and content-type as the same header
all header values are strings, so if a header value is not a string, the server will respond with a 400 Bad Request status code
if a header is not in the list of headers that the standard mentions, the server will respond with a 400 Bad Request status code
if a header is merely not supported by the server, the server will ignore the header, or respond with a 501 Not Implemented status code

`body` - `object`, required

the body of the request
the body can contain key-value pairs following the same rules as the headers field
however, the body must also contain two subfields, content and encoding

`content` - `string`, required

the raw text to be sent as the body of the request.
if the content field is not present, the request is either a POST or PUT request, and the header "expect": "100-continue" is not present, the server will respond with a 400 Bad Request status code

`encoding` - `string`, required

the encoding of the content field
below are the list of allowed encodings:
- gzip
- deflate
- br (Google's Brotli)
- identity (no encoding)
if the encoding is not in the list above, the server will respond with a 412 Precondition Failed status code

The 100-Continue Header

if the client is planning to send a large request, it can send the header "expect": "100-continue" to the server
this tells the server to bear in mind that the client is planning to send a large request, and so it should not timeout as quickly
if the server does not support the 100-Continue header, it will respond with a 501 Not Implemented status code
if the server supports the 100-Continue header, it will respond with a 100 Continue status code, and the client can then send the full request, in the same format as above. Notably different from HTTP, the full request is sent, not just the body
example of a request with the 100-Continue header:

{
    "jsontp": "1.0",
    "type": "request",
    "resource": "/path/to/resource",
    "method": "GET",

    "headers": {
        "expect": "100-continue" // required (obviously!)
    },

    "body": {} // if not empty, it will be ignored
}

once the server responds with a 100 Continue status code, the client can send the full request, in the same format as above

Example Request

{
    "jsontp": "1.0",
    "type": "request",
    "resource": "/index.html",
    "method": "POST",

    "headers": {
        "accept": "text/html",
        "accept-encoding": "gzip, deflate",
    },

    "body": {
        "content": "key1=value1&key2=value2&key3=value3",
        "encoding": "identity"
    }
}

Response

the response message is sent by the server to the client
it is sent in response to a request message
the response message is in the form of a JSON object

Response Format

{
    "jsontp": "1.0",
    "type": "response",
    "status": {
        "code": 200,
        "formal-message": "OK",
        "human-message": "The request was successful."
    },
    "resource": "/path/to/resource",
    "headers": {
        "date": "2024-01-01T00:00:00Z+00:00",
        "language": "en-GB",
    },
    "body": {
        "key1": "value1",

        "content": "raw text to be sent",

        "encoding": "gzip"
    }
}

Fields

if a required field is not present, the client might not be able to process the response, so it is vital that all fields are present

`jsontp` - `string`, required

the version of the jsontp standard that the message follows
it is always in the form major.minor(-rcx), where x is the release candidate number
for example, 1.0, 1.1, 1.2-rc1, etc.

`type` - `string`, required

the type of message, which in this case is response.

`status` - `object`, required

the status of the response
it has three required subfields - code, formal-message, and human-message

`code` - `number`, required

the status code of the response, which must be a valid HTTP status code
below are some examples of valid code fields:
- 200
- 404
- 500
- 418
- 503

`formal-message` - `string`, required

the formal message of the status code
this is the message corresponding to the status code
below are some examples of valid formal-message fields:
- OK
- Not Found
- Internal Server Error
- I'm a teapot
- Service Unavailable
this is case-insensitive

`human-message` - `string`, required

the human-readable message of the status code
this is a message that is intended for the user to read, and is not intended to be parsed by a machine
therefore, it is not standardised, and can be anything, at the discretion of the server
below are some examples of valid human-message fields:
- The request was successful.
- The resource was not found.
- The server encountered an error.
- I'm a teapot.
- The server is currently unavailable.

`resource` - `string`, required

the path to the resource that the client is requesting
though this was sent in the request message, it is also sent in the response message, so that the client can verify that the server is responding to the correct request, and the data has not been mangled in transit, or mistaken by the server

`headers` - `object`, required

the headers to send with the response
the keys are the header names, and the values are the header values
in the response field there are two required headers - date and language

`date` - `string`, required

the date and time that the response was sent
it is in the form YYYY-MM-DDTHH:MM:SSZ+0000, where Z is the timezone offset
it should be in the UTC timezone, but if it is not, the server should include the timezone offset, with no colon and no space between the Z and the offset
for example, 2024-01-01T00:00:00Z+0000, 2024-01-01T00:00:00Z-0500, 2024-01-01T00:00:00Z+0530, etc.

`language` - `string`, required

the language header is used to tell the client the language of the response.
the language must be in the format ISO 639-1 language code, followed by a hyphen, and then a valid ISO 3166 Alpha 2 country code.
for example, en-GB, en-US, fr-FR, de-DE, etc.

Headers

jsontp headers are the headers that are sent with the request and response messages
they are more strictly defined than HTTP headers, and are designed to be more reliable
however, they are still very similar to HTTP headers, and are designed to be easy to understand and implement
unlike HTTP headers, jsontp headers are case-insensitive

Shared headers

`content-type`

The content-type header is used to specify the type of the content in the message body.
It is a valid MIME type.
If it is sent from the client, and the server does not support the specified type, it should respond with a 415 Unsupported Media Type status code.

Request headers

all request headers are optional

`accept-encoding` - `array` or `string`

the accept-encoding header is used to specify the encoding that the client can accept
it is a list of encodings, in order of preference
if it is a string, it is a single encoding
if it is an array, it is a list of encodings
if the server does not support the specified encoding, it should respond with a 412 Precondition Failed status code
valid encodings are gzip, deflate, br, identity (no encoding)

`accept-language` - `array` or `string`

the accept-language header is used to specify the language that the client can accept
much like the accept-encoding header, it is a list of languages, in order of preference
if the server does not support the specified language, it should respond with a 406 Not Acceptable status code
valid languages are ISO 639-1 language codes, followed by a hyphen, and then a valid ISO 3166 Alpha 2 country code
e.g. en-US, fr-CA

`authorization` - `string`

the authorization header is used to specify the credentials that the client is using to authenticate itself
the value is a string, the exact format of which is determined by the server's configuration

`cookies` - `object`

the cookies header is used to specify the cookies that the client has
it is an object, where the keys are the names of the cookies, and the values are the cookies themselves
e.g. {"cookie1": "value1", "cookie2": "value2"}
if they are in an invalid format, the server will respond with a 400 Bad Request status code

`if-modified-since` - `string`

the if-modified-since header is used to tell the server to only send the message if it has been modified since the specified date
the value is a string, in the format %Y-%m-%dT%H:%M:%SZ%z
if it has not been modified, the server will respond with a 304 Not Modified status code

`if-unmodified-since` - `string`

the if-unmodified-since header is used to tell the server to only send the message if it has not been modified since the specified date
the value is a string, in the format %Y-%m-%dT%H:%M:%SZ%z
if it has been modified, the server will respond with a 412 Precondition Failed status code

`expect` - `string` (only `100-continue` is supported)

the expect header is used to tell the server to only send the message if the specified condition is met
the only supported value is 100-continue
if the server does not support the specified condition, it should respond with a 501 Not Implemented status code

`ignore-invalid-headers` - `boolean`

the ignore-invalid-headers header is used to tell the server to ignore any headers that it does not understand
if set to true, the server will ignore any headers that it does not understand
if set to false, the server will respond with a 400 Bad Request status code if it encounters any headers that it does not understand
should be false by default

Response headers

`date` - `string`, required

the date header is used to specify the date and time at which the message was sent.
it is always in the format %Y-%m-%dT%H:%M:%SZ%z.
it should be in UTC time.
e.g. 2019-01-01T00:00:00Z+0000

`language` - `string`, required

the language header is used to specify the language of the message body.
it is in the format ISO 639-1 language code, followed by a hyphen, and then a valid ISO 3166 Alpha 2 country code.
e.g. en-US, fr-CA

`set-cookies` - `object`, required

the set-cookies header is used to specify the cookies that should be set on the client.
it is an object, where the keys are the names of the cookies, and the values are the cookies themselves.
e.g. {"cookie1": "value1", "cookie2": "value2"}
if they are in an invalid format, the server will respond with a 400 Bad Request status code.

Status Codes

jsontp uses HTTP status codes to indicate the success or failure of a request.
any valid HTTP status code is a valid jsontp status code - the only difference is that the message body is in JSON format.
while any status code can be used as the server sees fit, there are a few mentioned in the specification that are used in a specific way.

`505 HTTP Version Not Supported`

if the server does not support the version of jsontp that the client is using, it should respond with a 505 HTTP Version Not Supported status code.

`400 Bad Request`

if the server does not understand the request, it should respond with a 400 Bad Request status code.
this is mentioned numerous times in the specification, and is used in a variety of contexts.

`405 Method Not Allowed`

if the server does not support the method that the client is using, it should respond with a 405 Method Not Allowed status code.

`406 Not Acceptable`

if the server does not support the language that the client is using, it should respond with a 406 Not Acceptable status code.

`412 Precondition Failed`

used for conditional requests that cannot be met, or also in the case of the if-unmodified-since header when the resource has been modified

`415 Unsupported Media Type`

used for unsupported MIME types

`404 Not Found`

used for resources that do not exist

`304 Not Modified`

used for conditional requests that have not been modified

`501 Not Implemented`

used for unsupported conditions, such as the expect header

jsontp versioning

the jsontp version is in the format major.minor(-rcx)
the major version is incremented when there are breaking changes the minor version is incremented when there are non-breaking changes (though this may never happen)
the rcx is the release candidate number, and will only be present in a release candidate version, for example, 1.0-rc1. It will not be present in a stable release. If it is present, it should be incremented with each release candidate, and omitted in the stable release.
the jsontp version is always in the jsontp key-value pair, which is mandatory in all jsontp messages.
if the jsontp version is not supported, the server should respond with a 505 HTTP Version Not Supported status code.
if the jsontp version is not provided, the server should respond with a 400 Bad Request status code.
examples: 1.0, 1.2-rc3, 2.3

`jsontp` - version `1.0-rc2`

json is the ubiquitous data interchange format for the web
HTTP is the ubiquitous protocol for the web
but HTTP is not easy to parse
jsontp is an protocol that uses json as its data interchange format
the HTTP specification is often changed, whilst the json specification is stable
the jsontp protocol is designed to be easy to parse and easy to generate
the jsontp protocol is sent over TCP

the `jsontp` protocol

there are two types of jsontp messages: request and response
a request message is sent from client to server, and a response message is sent from server to client

graph TD
    A[Client] -->|request| B[Server]
    B -->|response| A

the `jsontp` request message

the jsontp request message is sent from the client to the server
it must always include:
- the jsontp key-value pair
- the type key-value pair
- the resource key-value pair
- the method key-value pair
- the headers object (no mandatory headers in the request, but must always be present even if empty, in which case it should be {})
- the body object
- the body object must always include:
  - the content key-value pair
  - the encoding key-value pair

{
    "jsontp": "1.0", // required and in the format `major.minor`
    "type": "request",
    "resource": "/path/to/resource",
    "method": "GET",

    "headers": { // no required headers in the request
        "key1": "value1",
    },

    "body": {
        "key1": "value1", // optional

        "content": "raw text to be sent", // must always be present, even if empty

        "encoding": "gzip" // required, but can be `identity` if no encoding is used
    }
}

the `jsontp` response message

the jsontp response message is sent from the server to the client
it must always include:
- the jsontp key-value pair
- the status object
- the resource key-value pair
- the headers object
- the body object
- the status object must always include:
  - the code key-value pair
  - the formal-message key-value pair
  - the human-message key-value pair
- the headers object must always include:
  - the date key-value pair
  - the language key-value pair
- the body object must always include:
  - the content key-value pair
  - the encoding key-value pair

{
    "jsontp": "1.0", // required and in the format `major.minor(-rcx)` (explained more in the `jsontp` versioning section)
    "type": "response",
    "status": {
        "code": 200, // a valid `HTTP` status code (not 1xx)
        "formal-message": "OK", // a valid `HTTP` status message
        "human-message": "The request was successful." // a human-readable message, the contents of which is up to the discretion of the server, but should be helpful to the client. It is required, but can be a copy of the `formal-message` if the server wishes.
    },
    "resource": "/path/to/resource",
    "headers": {
        "date": "2024-01-01T00:00:00Z+00:00", // required and always in this format. Should always be in UTC, but a compliant client should accept any timezone
        "language": "en-US", // required and always in this format (explained more in the `response` headers section)
    },
    "body": {
        "key1": "value1", // optional

        "content": "raw text to be sent", // must always be present, even if empty

        "encoding": "gzip" // required, but can be `identity` if no encoding is used
    }
}

the `jsontp` 100 Continue request message

{
    "jsontp": "1.0", // required and in the format `major.minor`
    "type": "request",
    "resource": "/path/to/resource",
    "method": "GET",

    "headers": {
        "expect": "100-continue" // required
    },

    "body": {} // if not empty, it will be ignored
}

the `jsontp` 100 Continue response message

{
    "jsontp": "1.0", // required and in the format `major.minor(-rcx)` (explained more in the `jsontp` versioning section)
    "type": "response",
    "status": {
        "code": 100, // either 100, or a 4xx or 5xx error code
        "formal-message": "CONTINUE", // corresponding status code
        "human-message": "Ackknowledgement on the 100 Continue message"
    },
    "resource": "/path/to/resource",
    "headers": {
        "date": "2024-01-01T00:00:00Z+00:00", // required and always in this format. Should always be in UTC, but a compliant client should accept any timezone
        "language": "en-US", // required and always in this format (explained more in the `response` headers section
    },
    "body": {} // should be empty, ignored if not
}

content requirements of certain key-value pairs

`jsontp`

the jsontp key-value pair is always in the format major.minor(-rcx)
this is explained more in the jsontp versioning section
if the jsontp version is not supported, the server should respond with a 505 HTTP Version Not Supported status code
if the jsontp version is not provided, the server should respond with a 400 Bad Request status code

`type`

must be either request or response
if the type is not supported, the server should respond with a 400 Bad Request status code

`method`

the method key-value pair is the HTTP method that the client is using to request the resource
the method key-value pair can be any of the following:
- GET
  - standard request for the resource, which follows the request specification exactly
- POST
  - same as get, but the server must attempt to parse the body as a &-separated list of key-value pairs. If not, that is no problem, and the server can proceed as usual
- PUT
  - the resource is to be created or replaced with the content of the body
  - if successful, the server should respond with a 201 Created status code
- DELETE
  - the resource is to be deleted
  - the body should be ignored.
  - if successful, the server should respond with a 204 No Content status code
- OPTIONS
  - the server should respond with a 200 OK status code, and the body should contain a key entitled allowed-methods, and the value should be an array of the allowed methods.
  - It should ignore the body of the request message.
if the method is not supported, the server should respond with a 405 Method Not Allowed status cod
a compliant server must implement at least the GET and OPTIONS methods

`status`

the status key-value pair is always an object

`code`

the code key-value pair is always a valid HTTP status code (not 1xx).

`formal-message`

the formal-message key-value pair is always a valid HTTP status message corresponding to the code, for example, OK for 200, Not Found for 404, etc. It is case-insensitive.

`human-message`

the human-message key-value pair is always a human-readable message, the contents of which is up to the discretion of the server, but should be helpful to the client. It is required, but can be a copy of the formal-message if the server wishes.

`resource`

the resource key-value pair is the path to the resource that the client is requesting
the resource key-value pair can be in any of the following formats:
- /path/to/resource
- /path/to/resource/
- path/to/resource
- path/to/resource/
- site.com/path/to/resource
- jsontp://site.com/path/to/resource
if the resource format is not supported, the server should respond with a 400 Bad Request status code
if the resource is not found, the server should respond with a 404 Not Found status code

valid headers

headers are always in the format { "key": "value" }
the key is always a string, and the value can be any type bar undefined and null
the key is always case-insensitive
the value is always case-sensitive
if an invalid header is provided, the server should respond with a 400 Bad Request status code, however, this shouldn"t happen if the header ignore-invalid-headers is set to true

`headers` in `request` and `response` messages

`content-type` - `string`

the MIME type of the body or content of the message
if the MIME type is not supported, the server should respond with a 415 Unsupported Media Type status code

`accept` - `array` or `string`

the MIME type of the body or content that the client is willing to accept.
If the server cannot provide the MIME type, it should respond with a 415 Unsupported Media Type status code.
If there are multiple allowed MIME types, they should ideally be a json array, but a string is also acceptable.
For example: ["text/html", "application/json", "application/xml"] or "text/html, application/json, application/xml"

`request` headers

`accept-encoding` - `array` or `string`

the encoding that the client is willing to accept.
If the server cannot provide the encoding, it should respond with a 412 Precondition Failed status code.
If there are multiple allowed encodings, they should ideally be a json array, but a string is also acceptable.
For example: ["gzip", "deflate", "br", "identity"] or "gzip, deflate, br, identity"
Allowed encodings are: gzip, deflate, br, identity

`accept-language` - `array` or `string`

the language that the client is willing to accept.
If the server cannot provide the language, it should respond with a 406 Not Acceptable status code.
If there are multiple allowed languages, they should ideally be a json array, but a string is also acceptable.
For example: ["en-US", "en-GB", "en-CA"] or "en-US, en-GB, en-CA"
Each must first be a valid ISO 639-1 language code, followed by a hyphen, and then a valid ISO 3166 Alpha 2 country code.

`authorization` - `string`

the authorization header is used to authenticate the client with the server.
the authorization header should be in the format <token>, where <token> is the token that the server has provided to the client.
if the server cannot authenticate the client, it should respond with a 401 Unauthorized status code.

`cookies` - `object` or `string`

the cookies header is used to send cookies to the server.
the cookies header should be a small json object, with the keys being the cookie names, and the values being the cookie values.
if the server cannot accept the cookies, it should respond with a 400 Bad Request status code.
example: "cookies": {"cookie1": "value1", "cookie2": "value2"}
however, a compliant server will also accept cookies in the format "cookie1=value1; cookie2=value2", as this is the format that the HTTP specification uses, and jsontp is designed to be maximally compatible with existing standards.

`if-modified-since` - `string` in the strftime format (that found given in `man 3 strftime`) `%Y-%m-%dT%H:%M:%SZ%z`

the if-modified-since header is used to tell the server that the client only wants the resource if it has been modified since the date provided.
the date should be in the format %Y-%m-%dT%H:%M:%SZ%z, and should always be in UTC, but a compliant server should accept any timezone (although it should convert it to UTC before comparing it to the last modified date of the resource, which should always be in UTC).
if the server cannot provide the resource, it should respond with a 412 Precondition Failed status code.
if the server could provide the resource, but it has not been modified since the date provided, it should respond with a 304 Not Modified status code.
example value: 2024-01-01T00:00:00Z+0000 (no colon is permitted in the timezone offset)

`if-unmodified-since` - `string` in the strftime format (that found given in `man 3 strftime`) `%Y-%m-%dT%H:%M:%SZ%z`

the if-unmodified-since header is used to tell the server that the client only wants the resource if it has not been modified since the date provided.
the date should be in the format %Y-%m-%dT%H:%M:%SZ%z, and should always be in UTC, but a compliant server should accept any timezone (although it should convert it to UTC before comparing it to the last modified date of the resource, which should always be in UTC).
if the server cannot provide the resource, it should respond with a 412 Precondition Failed status code.
if the server could provide the resource, but it has been modified since the date provided, it should respond with a 412 Precondition Failed status code. Unfortunately, the HTTP specification does not provide a status code for this (3xx Modified), so jsontp has to use 412 Precondition Failed instead, as does the HTTP specification.
example value: 2024-01-01T00:00:00Z+0000 (no colon is permitted in the timezone offset)

`expect` - `string` (namely `100-continue`)

used to tell the server that the body will be sent in the next request, and not to time out quickly
first, the client sends a message in the format specified above, then the server responds, again set out above. If the server does not support 100-continue, it must respond with a 501 Not Implemented status code, at which point the connection will terminate.
if the server responds with 100 Continue, the client then sends its request in the usual fashion, containing all required fields, including headers. The client can modify the headers for this second request if they need to for some reason.
ignore-invalid-headers - boolean
if the ignore-invalid-headers header is set to true, the server should ignore any invalid headers, and not respond with a 400 Bad Request status code.
if the ignore-invalid-headers header is set to false, the server should respond with a 400 Bad Request status code if any invalid headers are provided.

`response` headers

`date` - `string` in the strftime format (that found given in `man 3 strftime`) `%Y-%m-%dT%H:%M:%SZ%z`

the date header is used to tell the client the date and time that the response was generated.
the date should be in the format %Y-%m-%dT%H:%M:%SZ%z, and should always be in UTC, but a compliant client should accept any timezone.
if the server cannot provide the date, it should respond with a 500 Internal Server Error status code.
this header is always present in a response message.
example value: 2024-01-01T00:00:00Z+0000 (no colon is permitted in the timezone offset)

`language` - `string`

the language header is used to tell the client the language of the response.
the language must be in the format ISO 639-1 language code, followed by a hyphen, and then a valid ISO 3166 Alpha 2 country code.
if the language does not match this format, the server should respond with a 400 Bad Request status code.
if the server cannot provide the language, it should respond with a 500 Internal Server Error status code.

`set-cookies` - `object`

the set-cookies header is used to tell the client to set cookies.
the set-cookies header should be a small json object, with the keys being the cookie names, and the values being the cookie values.
example: "set-cookies": {"cookie1": "value1", "cookie2": "value2"}
the server must respond with an object, not a string, as the HTTP specification does not allow for multiple set-cookie headers to be sent in a single response, and so jsontp must use a json object to represent multiple cookies.

Other important requirements

`jsontp` versioning

the jsontp version is in the format major.minor(-rcx)
the major version is incremented when there are breaking changes
the minor version is incremented when there are non-breaking changes (though this may never happen)
the rcx is the release candidate number, and will only be present in a release candidate version, for example, 1.0-rc1. It will not be present in a stable release. If it is present, it should be incremented with each release candidate, and omitted in the stable release.
the jsontp version is always in the jsontp key-value pair, which is mandatory in all jsontp messages.
if the jsontp version is not supported, the server should respond with a 505 HTTP Version Not Supported status code.
if the jsontp version is not provided, the server should respond with a 400 Bad Request status code.

errors on the server's side

if the server encounters an error, it should respond with a 5xx Server Error status code.
the message key-value pair in the status object should be a human-readable error message.

where to submit feature requests

feature requests can be submitted to the jsontp/paper GitHub repository, or can be emailed directly to the jsontp maintainers, the email address of which is provided in the jsontp GitHub organization.

comments

comments should not be included in any message, but a compliant implementation should allow them.

The `"expect": "100-continue"` header

This is explained in the section on the valid client headers, but below is a nice mermaid diagram

sequenceDiagram
Client ->> Server: body-less request
Server ->> Client: 100 continue response (or 501, if so the connection ends)
Client ->> Server: full request
Server ->> Client: full response