diff --git a/rfcs/GraphQLOverSSE.md b/rfcs/GraphQLOverSSE.md index ecf7edf7..b1aa1df3 100644 --- a/rfcs/GraphQLOverSSE.md +++ b/rfcs/GraphQLOverSSE.md @@ -59,11 +59,11 @@ interface CompleteMessage { Having aforementioned limitations in mind, a "single connection mode" is proposed. In this mode, a single established SSE connection transmits **all** results from the server while separate HTTP requests dictate the behaviour. -Additionally, due to various limitations with the browser's native [`EventSource` interface](https://developer.mozilla.org/en-US/docs/Web/API/EventSource), like the lack of supplying custom headers or vague connection error information, a "reservation" tactic is RECOMMENDED. This means that the client requests an SSE connection reservation from the server through a regular HTTP request which is later fulfiled with the actual SSE connection matching the reservation requirements. +Additionally, due to various limitations with the browser's native [`EventSource` interface](https://developer.mozilla.org/en-US/docs/Web/API/EventSource), like the lack of supplying custom headers or vague connection error information, a "reservation" tactic is RECOMMENDED. This means that the client requests an SSE connection reservation from the server through a regular HTTP request which is later fulfilled with the actual SSE connection matching the reservation requirements. ### Making reservations -The client requests a reservation for an incoming SSE connection through a `PUT` HTTP request. Since this is a regular HTTP request, it may transmit authentication details however the implementor sees fit. +The client requests a reservation for an incoming SSE connection through a `PUT` HTTP request. Since this is a regular HTTP request, it may transmit authentication details however the implementer sees fit. The server accepts the reservation request by responding with `201` (Created) and a reservation token in the body of the response. This token is then presented alongside the incoming SSE connection as an entrance ticket. If using the [`EventSource` interface](https://developer.mozilla.org/en-US/docs/Web/API/EventSource), the token may be encoded in the URL's search parameters. @@ -78,7 +78,7 @@ For security reasons, **only one** SSE connection can fulfil a reservation at a While having a single SSE connection (or reservation), separate HTTP requests solicit GraphQL operations conforming to the [GraphQL over HTTP spec](https://github.com/graphql/graphql-over-http/blob/main/spec/GraphQLOverHTTP.md) with **only one difference**: successful responses (execution results) get accepted with a `202` (Accepted) and are then streamed through the single SSE connection. Validation issues and other request problems are handled as documented in the [GraphQL over HTTP spec](https://github.com/graphql/graphql-over-http/blob/main/spec/GraphQLOverHTTP.md). -Since the client holds the task of publishing the SSE messages to the relevant listeners through a single connection, an operation ID identifying the messages destinations is necessary. The unique operation ID SHOULD be sent through the `extensions` parameter of the GraphQL reqeust inside the `operationId` field. This operation ID accompanies the SSE messages for destination discovery (more details below). +Since the client holds the task of publishing the SSE messages to the relevant listeners through a single connection, an operation ID identifying the messages destinations is necessary. The unique operation ID SHOULD be sent through the `extensions` parameter of the GraphQL request inside the `operationId` field. This operation ID accompanies the SSE messages for destination discovery (more details below). The HTTP request MUST contain the matching reservation token. diff --git a/rfcs/GraphQLOverWebSocket.md b/rfcs/GraphQLOverWebSocket.md index 9073f87e..14cf2b9a 100644 --- a/rfcs/GraphQLOverWebSocket.md +++ b/rfcs/GraphQLOverWebSocket.md @@ -104,7 +104,7 @@ Requests an operation specified in the message `payload`. This message provides If there is already an active subscriber for an operation matching the provided ID, regardless of the operation type, the server **must** close the socket immediately with the event `4409: Subscriber for already exists`. -The server needs only keep track of IDs for as long as the subscription is active. Once a client completes an operation, it is free to re-use that ID. +The server needs only keep track of IDs for as long as the subscription is active. Once a client completes an operation, it is free to reuse that ID. ```typescript interface SubscribeMessage { @@ -176,7 +176,7 @@ Direction: **bidirectional** Receiving a message of a type or format which is not specified in this document will result in an **immediate** socket closure with the event `4400: `. The `` can be vaguely descriptive on why the received message is invalid. -Receiving a message (other than `Subscribe`) with an ID that belongs to an operation that has been previously completed does not constitute an error. It is permissable to simply ignore all _unknown_ IDs without closing the connection. +Receiving a message (other than `Subscribe`) with an ID that belongs to an operation that has been previously completed does not constitute an error. It is permissible to simply ignore all _unknown_ IDs without closing the connection. ## Examples diff --git a/rfcs/IncrementalDelivery.md b/rfcs/IncrementalDelivery.md index 5baba5e7..3f1544ff 100644 --- a/rfcs/IncrementalDelivery.md +++ b/rfcs/IncrementalDelivery.md @@ -18,7 +18,7 @@ Compliant servers must follow the HTTP/2 specification and not set the `Transfer ## `Content-Type: multipart/mixed` -The HTTP response for an incrementally delivered response should conform to the [specification of multipart content defined by the W3 in rfc1341](https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html). The HTTP response must contain the `Content-Type` response header with a specified boundary, for example `Content-Type: multipart/mixed; boundary="-"`. A simple boundary of `-` can be used as there is no possiblity of conflict with JSON data. However, any arbitrary boundary may be used. +The HTTP response for an incrementally delivered response should conform to the [specification of multipart content defined by the W3 in rfc1341](https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html). The HTTP response must contain the `Content-Type` response header with a specified boundary, for example `Content-Type: multipart/mixed; boundary="-"`. A simple boundary of `-` can be used as there is no possibility of conflict with JSON data. However, any arbitrary boundary may be used. An example response body will look like: diff --git a/working-group/agendas/2020/2020-01-28.md b/working-group/agendas/2020/2020-01-28.md index ba505f44..d4eda1a8 100644 --- a/working-group/agendas/2020/2020-01-28.md +++ b/working-group/agendas/2020/2020-01-28.md @@ -71,4 +71,4 @@ _Planned for next meeting_ _Later_ - [ ] ???? - Draft a standard sample schema - Dependent on list of things to test -- [ ] Create sample servers to help test compliancy (i.e. graphql-express, graphql-api-koa, etc) +- [ ] Create sample servers to help test compliance (i.e. graphql-express, graphql-api-koa, etc)