Provide opt-in for Expect = "100-continue"

[annevk]

We could avoid teeing the request body with this protocol feature: http://httpwg.github.io/specs/rfc7231.html#header.expect

We would need to decide how much of the protocol is implemented in Fetch and how much we leave up to developers.

[annevk]

@tyoshino @mnot @wanderview @nikhilm do we still want this given the conclusion in #42?

[annevk]

Also, @mnot, it does not seem like this header guarantees there will be no redirects.

[mnot]

No, it doesn't.

Expect/Continue is a mechanism for avoiding unnecessary transfer of the request body; it won't help you avoid buffering it.

I think what you want to do is assure that developers can use expect/continue. It might be useful to have fetch do it natively too, but I think it's a very implementation-specific decision.

Question: How does Fetch handle these sorts of genuinely optional, implementation-specific behaviours? In other places I see hand-waving about "do whatever HTTP stuff you want to do", but here it's pretty intrusive into the request handling model.

I suppose you might do that by putting a note in to the effect "You can make an implementation choice to support Expect/Continue HERE, but we leave the details as an exercise for the reader."

[annevk]

Ideally, if it's not specified, it's not allowed. But there's still quite a bit of handwaving the lower on the stack you go. Servers seem to rely on clients behaving in a certain way. I'm sure they're not going to be happy if we start sending them these headers without optin.

[mnot]

Servers already get Expect on requests with bodies, and have to deal with it. Really, Expect itself is a form of opt-in (for the request).

Even without the teeing optimization, supporting Expect: 100-continue could be useful for large requests, in particular file uploads. The server may be able to respond immediately with an error (like a 401 or 403), meaning that clients for whom network usage is important (mobile in particular) can avoid wasting network on a request whose body will be ignored.

[annevk]

@mnot Expect is a forbidden header name at the moment. But even if we lift that, we can only handle a single response. I'm not sure how we'd adjust the API signature for a stream(?) of responses.

Could Fetch handle the 100-continue transparently? Or would that just lead to requests not to and let the client handle it?

[annevk]

@scshunt we could let the client handle them and let the client handle when to transmit the request body (if the 100 response never shows). I thought we maybe wanted to expose them. Letting the client handle them certainly makes things easier.

[mnot]

I think that's what you'd want to do.

Note that Expect/Continue has lots of problems; defining its behaviour in fetch might help some of them, if it's done carefully.

[annevk]

First step here is probably fixing #366.