Allow for arbitrary boundaries in incremental delivery RFC

[benjie]

As discussed/agreed here: #124 (comment)

CC @robrichard

[spawnia]

I imagine interoperability to be easier if the boundary is prescribed to always be the same. How are different boundaries useful or necessary?

[jaydenseric]

For multipart requests, boundaries are meant to be a string that doesn't occur anywhere in the content. Implementations such as FormData/fetch in browsers generate gnarly random looking boundaries; I'm not sure if they are deterministically generated based on the content or if they differ each request.

As stated previously, each body part is preceded by an encapsulation boundary. The encapsulation boundary MUST NOT appear inside any of the encapsulated parts. Thus, it is crucial that the composing agent be able to choose and specify the unique boundary that will separate the parts.
— https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html

[benjie]

I imagine interoperability to be easier if the boundary is prescribed to always be the same. How are different boundaries useful or necessary?

Interoperability is easier if the boundary is not prescribed because, as Jayden mentions, many clients automatically generate the boundaries. If we prescribe it, people may have to write their own multipart clients.

[jaydenseric]

Interoperability aside I don't think a specific string can be specified, otherwise if any of the data contains that string the response content is invalid. If a single dash char (-) is the specified boundary, what if you have to transfer data like this (containing 3 - chars):

{
  "name": "Mary-Louise Smith",
  "birthday": "1990-01-02"
}

[benjie]

I don't believe that situation can occur in JSON:

Note that the encapsulation boundary must occur at the beginning of a line, i.e., following a CRLF, and that that initial CRLF is considered to be part of the encapsulation boundary rather than part of the preceding part. The boundary must be followed immediately either by another CRLF and the header fields for the next part, or [...]

The closest you could get would be including - followed by a number:

{
  "number":
-1
}

[robrichard]

I also don't think there is the possibility of a boundary of - conflicting with JSON data as the boundary needs to be preceded by a CRLF and a prefix of --, but I agree it should be supported.

I opened a PR to update the RFC to state that arbitrary boundaries are allowed: #143

I also updated my client library fetch-multipart-graphql (mentioned in the RFC) to support arbitrary boundaries. I will keep my express-graphql PR with the hardcoded - boundary.

[IvanGoncharov]

@benjie Can I close this issue since we merged #143?

[benjie]

Yep 👍