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
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.
Received on Wednesday, 11 June 1997 12:26:53 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:44 EDT