> What specific section in the RFC are reading when you say that the
> client is
> expected to continue to the POST even though no 100 continue arrived?
> My
> interpretation of the 100-continue is that we require the 100 code
> reponse
> before we send anything, and if we don't get it we don't send anything.
>
> You quoted this section:
>
> - A client MUST NOT send an Expect request-header field (section
> 14.20) with the "100-continue" expectation if it does not intend
> to send a request body.
>
> And I think that paragraph only confirms my view of things. The client
> *does*
> intend to send the body, it just needs clearance first.
>
>> so the next 308 bytes it gets are "read and discarded" according to
>> the RFC.
>
> This is painfully true.
>
> Argh, I don't see the point in having this behavior defined like this!
> It
> makes no sense at all at it makes operation such as this slower.
>
> But do note that the RFC states "it MAY continue to read and discard
> the rest
> of the request". MAY being the keyword. It doesn't _have to_ and I
> claim it is
> stupid to do so. Especially since it also says "It MUST NOT perform the
> requested method if it returns a final status code."
>
> But of course, having "MAY" in the spec like that leads to what we see
> here
> and I bet there will be server that reads that MAY the other way...
>

I talked to the MS guy about this for quite a while... we agreed that
this section of the RFC was unclear. The "may" should have been moved
to indicate that the CHOICE is in which *way* to handle the situation
rather than to indicate the subsequent behavior is optional...

Reads: "If it responds with a final status
         code, it MAY close the transport connection or it MAY continue
         to read and discard the rest of the request."

SHOULD read: "If it responds with a final status
         code, it MAY EITHER close the transport connection or continue
         to read and discard the rest of the request."

The reason it HAS to do this... if the client posts a POST message with
a non-zero content length, sends the header and an Expect/Continue
header, then the server responds with a FINAL status... under your
initial reading (which I initially agreed with) the server could then
either READ AND DISCARD the remainder of the request OR start reading a
new request. The problem here is that the client has no way to tell the
server WHICH of those two scenarios to expect, and thus that reading of
the RFC would actually be more ambiguous.

Trust me, I really wanted to find an IIS bug but I am confident they're
doing the right thing here... :)

---------------

When you have a chance to think about the solution, let me know and
I'll play around. I checked the RFC and Content-Length of 0 is
completely legal, but I do see how it could be an area of risk for
other servers. I tend to think the "HEAD" route is a cleaner way to go
as from the client perspective we ALWAYS know whether or not we expect
the server to be able to respond to a given request, so we could easily
use HEAD until we know we're ready for the "final" request, with the
correct VERB as well as the entire POST body.

Alan
Received on 2004-03-26