Re: p2: Expect: 100-continue and "final" status codes

On Tue, Apr 23, 2013 at 9:19 PM, Mark Nottingham <mnot@mnot.net> wrote:

>
> On 24/04/2013, at 3:42 AM, Zhong Yu <zhong.j.yu@gmail.com> wrote:
>
> > #Expect 100-continue without a body
> >
> > If a client sends a request without a body yet with a "Expect:
> 100-continue" header, the request ought to be considered a bad request,
> because of a previous requirement:
> >
> >    o  A client MUST NOT send an Expect header field with the "100-
> >       continue" expectation if it does not intend to send a payload
> >       body.
> >
> > However a server may not be able to detect all bad requests. If it sees
> a request without a body, it may simply assume that there's no 100-continue
> expectation.
> >
> > The spec may add a leeway for server
> >
> >    o  Upon receiving a request with "100-continue" expectation yet
> without a message body (i.e. both Transfer-Encoding and Content-Length are
> missing), an origin server SHOULD either respond with 400 (Bad Request), or
> ignore the expectation.
>
> +1
>
>
> > #Performing request method without reading request body
> >
> > I don't understand why the origin server must not perform the request
> method if it opts not to read the request body. Even though it's probably
> the right thing to do in almost all cases, do we have to make it an
> absolute requirement?
>
> See below about recovery.
>
>
> > #Managing connection
> >
> > The last requirement for the origin server talks about requests
> *without* a "100-continue" expectation. Therefore it should not be in this
> section. The subject is covered very well in p1#6.6 already, I think we can
> simply delete it from this section.
>
> +0.5 - I tend to agree, but don't mind too much if it stays.
>
>
> > On the other hand, the spec does not address connection management
> adequately in the most important use case of the section. It currently says
> (paraphrasing)
> >
> >     upon receiving a request that includes the 100-continue expectation,
> if the origin server responds with a final status code instead of 100
> (Continue), after sending the response, it may either close the connection
> or continue to read and discard the rest of the request.
> >
> > I think we can give better advice than that. If a server responds with a
> final status code instead of 100 (Continue)
> >
> > 1. The response must be the last response on the connection. The
> response should contain "Connection: close" header. After the response is
> written, the server must initiate a lingering close of the connection
> (p1#6.6).
>
> That seems too restrictive; as long as the server reads the rest of the
> request properly (discarding it), it should be able to recover and reuse
> the connection.
>
>
You are right, scratch my proposal.


>
> > 2. If the client receives a final status code instead of 100 (Continue),
> it should stop sending request body if it is doing so; it must close the
> connection after the response is received.
>
> Well, it has a choice; it can either close the connection, or continue
> sending and recover the connection. If it only has a few more bytes to
> write, and some requests queued, that might be preferable.
>
> OTOH, given the general level of interop around Expect/Continue, maybe not.
>
>
> > This is to avoid the RST problem if the client decides to start to write
> request body before receiving any response from the server.
>
> I agree that the current language (esp. the use of MAY) is too ambiguous,
> and doesn't highlight why we're taking this approach (because the client
> might decide to start sending the body).
>
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>