Re: ISSUE: MUST a client wait for 100 when doing PUT or POST

Henrik Frystyk Nielsen:
>
[...]
>I don't believe I said that - the proposed resolution was:
>
>   a client SHOULD wait for a 100 (Continue) code before sending the
>   body but can send the whole thing if it believes that the server
>   will react properly.
>
>This covers exactly the situation of small POST requests, you are referring
>to. I believe that being conservative in the specification guaranteeing
>correct behavior but allowing optimized applications is better than the
>other way round.

I oppose this resolution.  You should not use SHOULD to mean

  `SHOULD if you are a stupid application and SHOULD NOT if you are an
  optimized application'

The consequences of ignoring a SHOULD should always be less a less
optimal application.

If you mean to say

   a very conservative client MAY wait for a 100 in order to decease
   the chance of <some bad thing> happening

then you should say that.

My opinion is that we should not try to re-think the 100 mechanism at
this point.  It would be really nice if the presentation of the 100
mechanisms in the spec were improved, but I see no big gain in
changing the mechanism itself.

I do not think that 100 is very valuable.  But now that we have it, we
should keep it as it is, for the sake of spec stability.

>Thanks,
>
>Henrik

Koen.