W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

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

From: Koen Holtman <koen@win.tue.nl>
Date: Wed, 11 Jun 1997 21:22:58 +0200 (MET DST)
Message-Id: <199706111922.VAA08697@wsooti08.win.tue.nl>
To: Henrik Frystyk Nielsen <frystyk@w3.org>
Cc: john@math.nwu.edu, dwm@xpasc.com, http-wg@cuckoo.hpl.hp.com, lawrence@agranat.com, rlgray@raleigh.ibm.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3511
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.


Received on Wednesday, 11 June 1997 12:26:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:20 UTC