Handling Expect/continue

[mnot]

We need to give advice on how proxies, etc. should handle Expect/continue interactions.

[martinthomson]

This is marked for the first implementable draft. @mnot do you still plan to submit a text proposal?

[michaelrsweet]

From my posts to the HTTP mailing list:

This is something that gets used extensively in printing to avoid sending gigabytes of print data to a printer that needs authentication for certain operations... Perhaps something to add to section 8.1.1, e.g.:

Use of Expect with 100 (Continue) response:

POST /ipp/print HTTP/1.1            HEADERS
Host; printer.example.org      ==>    - END_STREAM
Content-Type: application/ipp         + END_HEADERS
Transfer-Encoding: chunked              :method = post
Expect: 100-continue                    :scheme = ipp
                                        :host = printer.example.org
                                        :path = /ipp/print
                                        content-type = application/ipp
                                        expect = 100-continue

HTTP/1.1 100 Continue          ==>  HEADERS
                                      - END_STREAM
                                      + END_HEADERS
                                        :status = 100

{binary data from client}      ==>  DATA
                                      + END_STREAM
                                        {binary data}

HTTP/1.1 200 OK                ==>  HEADERS
Content-Type: application/ipp         - END_STREAM
Transfer-Encoding: chunked            + END_HEADERS
                                        :status = 200
{binary data from server}               content-type = application/ipp

                                    DATA
                                      + END_STREAM
                                        {binary data}

Failed response needing authentication:

POST /ipp/print HTTP/1.1            HEADERS
Host; printer.example.org      ==>    - END_STREAM
Content-Type: application/ipp         + END_HEADERS
Transfer-Encoding: chunked              :method = post
Expect: 100-continue                    :scheme = ipp
                                        :host = printer.example.org
                                        :path = /ipp/print
                                        content-type = application/ipp
                                        expect = 100-continue

HTTP/1.1 401 Unauthorized      ==>  HEADERS
Content-Type: text/html               - END_STREAM
Content-Length: 123                   + END_HEADERS
WWW-Authenticate: Basic ...             :status = 401
                                        www-authenticate = Basic ...
{HTML error message from server}

Then we'd also need a clarification in section 8.1.3 to allow a single HEADERS response frame with :status = 100.

[michaelrsweet]

An alternative is to simply do away with it and have the server respond as soon as it wants with the 401 status - with flow control the client won't get too far ahead of the server, and with streams we don't have to deal with the expense of closing the connection and bringing a new one up (something that you need to do with HTTP/1.1 if Expect isn't supported by the server...)

Either way we should say something about it to give guidance/recommendations on HTTP/1.1 solutions that are adding support for HTTP/2.0...

[mnot]

See pull request on #264; think that one will close this too.