- From: Koen Holtman <koen@win.tue.nl>
- Date: Wed, 11 Jun 1997 21:22:58 +0200 (MET DST)
- 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 UTC