- From: Klaus Weide <kweide@tezcat.com>
- Date: Thu, 4 Sep 1997 13:37:14 -0500 (CDT)
- To: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Wed, 3 Sep 1997, Roy T. Fielding wrote: > >How about turning that around? I.e., instead of prohibiting what > >is not explicitly allowed, as we do today, we should allow what > >is not explicitly prohibited. So, I would say "if putting the > >header in the trailer makes it too late to be useful, then we should > >prohibit that." > > I agree with Jeff in that it is generally better to give people as > much rope as possible. Overly restricting legitimate applications is > far more of a hazard than making it possible for implementers to hang > themselves; after all, it's a lot easier for implementers to learn what > works (and what doesn't) than it is for us to go back and change the > definition of a header field. The question is, will they just hang themselves with that rope, or will they hang others or acceptance of the protocol. In a previous exchange in the RE-VERSION thread, IIRC you argued that there was no good reason for a 1.1 client to insist on not receiving chunked, since the implementation was simple. (please correct me if my memory is wrong.) If some dynamic services start sending essential headers (which the client needs) in footers because it is easier to implement, which they would otherwise send before the body, user agent implementers will have a good reason to ask "How can I turn this off". Or to just not implement 1.1 and stay 1.0. Or are 1.1 user agents free to ignore any headers that come "too late", would they still be conformant? Klaus
Received on Thursday, 4 September 1997 11:43:08 UTC