Re: [whatwg/fetch] Request body streams should use chunked encoding (#966)

@yutakahirano Thanks for the ping, I missed your question. I'm not sure I understand what you mean by "attack" here. To attempt to summarize the discussions/iterations:

### Problem Statement
1. Chunked uploads are not widely deployed at Internet scale (i.e. both client and servers), so there are compatibility concerns.
2. These compatibility concerns involve questions of compatibility with the origin server, and with any [intermediates](https://github.com/whatwg/fetch/issues/966#issuecomment-554985629) on the path: [client-authorized intermediates](https://github.com/whatwg/fetch/issues/966#issuecomment-564655414) and [server-authorized intermediates](https://github.com/whatwg/fetch/issues/966#issuecomment-557981310).
    * We [know](https://github.com/whatwg/fetch/issues/966#issuecomment-555831179) and [expect](https://github.com/whatwg/fetch/issues/966#issuecomment-557981310) some intermediate compatibility issues

### Solutions to date
#### Origin/Server-side Intermediate 

1. [Do nothing](https://github.com/whatwg/fetch/issues/966#issuecomment-556557563) (e.g. because it's under the [full control](https://github.com/whatwg/fetch/issues/966#issuecomment-554535512) of the server operator)
2. Do nothing, but declare any issues are not our fault and must be fixed [by the server/intermediate](https://github.com/whatwg/fetch/issues/966#issuecomment-555824349)
3. Require HTTPS (to prevent accidental intermediates)
4. Require some [explicit advertisement/opt-in](https://github.com/whatwg/fetch/issues/966#issuecomment-554985629) by the server, even when same-origin
5. [Restrict to HTTP/2](https://github.com/whatwg/fetch/issues/966#issuecomment-554909494)

#### Client/Client-side Intermediate
1. [Restrict to HTTP/2](https://github.com/whatwg/fetch/issues/966#issuecomment-554985629), as the complexity for client intermediates goes down if they support HTTP/2, and if they don't support HTTP/2, it's a good sign they may have issues
    * Alternatively, if we don't restrict to HTTP/2, try to restrict to [some other property](https://github.com/whatwg/fetch/issues/966#issuecomment-564655414) of the connection that indicates an intermediate is likely present, yet without revealing more information about [the user to the server](https://github.com/whatwg/fetch/issues/966#issuecomment-564663418), which is hard.
2. Do a [preflight with a special header](https://github.com/whatwg/fetch/issues/966#issuecomment-559676518) and require the preflight response MUST come over [HTTP 1/1+](https://github.com/whatwg/fetch/issues/966#issuecomment-564470851)

### Challenge
At the core, the question is "We expect some things to break, because these [joints are not well oiled](https://www.imperialviolet.org/2016/05/16/agility.html)" - the broader context of UAs doing chunked uploading is rare today, and thus we expect servers and services are not prepared for it, even if it would be a nice feature to add. Similarly, we want to make sure that when adding a feature, servers don't have to try and deploy workarounds for client issues.

### Suggestion
The total set of requirements to minimize risk of incompatibilities that seem reasonable:
1. Require HTTPS. This prevents any unauthorized intermediates (i.e. not explicitly authorized by the server or the user) from breaking.
2. Require HTTP/2. This is to minimize, but perhaps not totally mitigate, the risk of client-side intermediates breaking.
    * This also reduces the complexities involved with HTTP/1.1 and client signaling, even when no intermediates are involved.
3. Continue to prohibit cross-origin streaming/chunking by default, and add an explicit header to allow a destination server to opt-in.
4. Require implementors to minimally support the above (i.e they MUST attempt to support chunked encoding if the above invariants hold)

If folks are uncomfortable with those requirements, and want to propose alternatives, it might be useful to figure out how each proposal addresses the client side and the server side issues. It may be that something better for the server makes it worse for the client. But when we talk "middleboxes", we're really thinking about two sets: one set which are in control of the origin (e.g. CDNs they've contracted with), and another set that they are not in control of (e.g. because the user configured them)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/966#issuecomment-573057154