Request body streams should use chunked encoding

[ddragana]

Chunked encoding in the client-server direction is not widely used on the web. Stand-alone apps use it, but browser(s?), at least Firefox, do not support it.

the chunked encoding from server to client is broken on some server (they are probably old once, I do not have any data about this).

I am wondering what kind of bugs we will get if we start using chunked encoding in the client-server direction.

should we limit request body streams only to h2? We definitely should restrict it to https.

[annevk]

cc @yoichio @yutakahirano

[yoichio]

To protect the legacy servers, the fetch spec states UA doesn’t allow no-cors requests to have a streaming body, and UA forces CORS preflight for any cross-origin request with a streaming body. [1]
Thus client and server are owned by single author.

[1] (https://fetch.spec.whatwg.org/#dom-request)

[annevk]

I think same-origin-policy-wise we indeed got it covered, but I think we should strongly consider not requiring clients to implement chunked encoding for uploads and require H2 as a minimum for upload streams.

If we do decide to implement chunked encoding for uploads requiring HTTPS would help avoid problematic middleware.

cc @whatwg/http

[MattMenke2]

Sending chunked uploads over the web without some sort of server advertisement of support also makes me pretty nervous about middle-box/server compat issues, though requiring a server advertisement first addresses the server issue.

I don't think we want to make chunked uploads an optional client feature, just from a cross-browser compatibility standpoint. If one browser supports it and others do not, seems like that would bite a lot of web developers.

Requiring H2 instead presents its own set of problems with SSL-decrypting middleboxes, but I, at least, am less concerned about breaking just those.

[ricea]

I think it would be a pity to introduce an H2 dependency as H2 won't work in all environments, which could push the need to carry a perpetual fallback code path onto applications.

However, the same middleboxes that are breaking H2 may also break H1 chunked uploads, so there may be no good choices.

I'd like to at least experiment with permitting it over H1. We can compare success rates for H1 and H2 and see if there is a significant difference.

[yutakahirano]

Requiring https sounds reasonable. I'm not sure about requiring H2...

We could instead add another header to the CORS preflight response (note that we already require preflight for all cross-origin requests).

[yutakahirano]

Anyway, I'd like to hear opinions from server side developers.

[ioquatix]

I am the engineer behind Ruby's async-http HTTP/1.x and HTTP/2 client & server and falcon which is a zero-configuration HTTP/1 & HTTP/2 server for Ruby web applications.

When I first started working on async-http it was not clear to me that bi-directional streaming was possible via HTTP/1. But there are several ways it can work:

a/ For HTTP/1.0 (and 1.1) you can leverage shutdown(WR) and use a request body without a content-length (and obviously connection: close). This is in violation of the spec but only slightly and in practice it does work in certain situations. We don't expose this by default since it violates the spec, but at least I wanted to comment on it since I played around with it and it allows bi-directional streaming without chunked encoding.

b/ For HTTP/1.1, using chunked encoding for the request body works perfectly and is completely standards compliant.

c/ For HTTP/2, obviously this is a non-issue.

Falcon supports (b) and (c) by default, out of the box.

I wanted to try this out and provide a way for others to try it out too, so I quickly threw together a remote echo server.

Firstly, you can get the client and server here: https://github.com/socketry/utopia-falcon-heroku/

The application is hosted on Heroku right now: https://utopia-falcon-heroku.herokuapp.com/

Response Streaming

http://utopia-falcon-heroku.herokuapp.com/beer/index?count=100

It is actually going via an HTTP/1.1 middle box and working perfectly.

Request Streaming

Locally (working)

Using the code above:

$ bundle install
$ falcon serve

To start the client:

$ rake echo URL=https://localhost:9292/echo/index

Type some lines and they will be echoed back in real time.

Heroku (not working?)

Run this on the client:

$ rake echo URL=https://utopia-falcon-heroku.herokuapp.com/echo/index

You should be able to type lines and get an interactive response, but it seems like the request might be getting buffered. I can add more logging on the server to see what is going on, and will report back.

Conclusion

I wish that we would focus on the standards more than the existing implementations. The point of the standard is to say how it should work. And the point of the engineer is to implement it. The standard can say "This should work on HTTP/1.1" and it's within the existing design parameters. The fact it doesn't work is a bug. By encoding this into the standard, you are essentially encoding buggy designs into the standard. If you do this repeatedly, I can imagine that we end up with a huge mess based on crappy implementations, and standards that are getting repeatedly more messy.

[ioquatix]

I did some more testing.

It seems that while Heroku supports streaming uploads, and streaming downloads, it doesn't support bi-directional streaming correctly.

The server log indicates it's receiving the individual lines I send it, but the response appears to be buffered until the request body is completed. I'm going to create an issue on the appropriate Heroku repo.

That being said, this should work. And if the standard can mandate that it should be supported by H1, then it requires all middle boxes to be upgraded to support it.

Given that the vast majority of existing infrastructure still runs on H1 - I think this is going to be necessary. This isn't just about client -> server, but client -> heroku -> server etc.

[bradisbell]

Are there more details about the reasoning behind the proposed restrictions?

Streamed HTTP PUT requests are made all the time. Many of these likely violate spec by not using chunked encoding but also not specifying content length (in the case of indefinite lengths, like live streaming media). Some do successfully use chunked encoding, but I don't have a sense for how widespread this is. In any case, it seems strange to limit what the browser can do out of a sort of protection for a server. I don't understand the reason for a server to declare that it supports chunked encoding from the client.

Is there a particular potential side effect that is the source for concern?