- From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
- Date: Fri, 05 Sep 1997 08:37:44 -0700
- To: Klaus Weide <kweide@tezcat.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>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.) Simple when compared to the benefits gained by requiring it, yes. The requirement is that they be able to recognize and parse it. >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. If a user agent needs a particular header field before the body, then a dynamic service is not going to send it in the footer. Yes, it would be compliant, but there are a lot of things you can do in HTTP that are compliant and yet will result in garbage on some user agents. I think it is wrong to list those things and make them non-compliant because not all user agents are alike, and not all servers are alike in their knowledge of the capabilities of the particular client to which they are talking. HTTP should be capable of transferring certain kinds of information even if it is sometimes unwise for it to do so on the open Internet. In this sense, we need to differentiate between capabilities of the protocol (what we are defining) and capabilities of a particular application of the protocol. The protocol requirements should not be dependent on the application, when possible. >Or are 1.1 user agents free to ignore any headers that come "too late", >would they still be conformant? I think that would be reasonable, provided that we have a definition of "too late". ....Roy
Received on Friday, 5 September 1997 08:48:22 UTC