- From: Albert Lunde <albert-lunde@nwu.edu>
- Date: Fri, 05 Sep 1997 11:07:21 CDT
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> 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".
I'd tend to lean towards enumerating a list of header-fields
permitted to occur in the footer, rather than making it wide-open.
The purpose of allowing stuff it the footer is to make it
easier for server process to provide dynamic context.
But allowing any field in the footer could impose an unnecessary
burden on, say, proxy implementors.
I'd say the reason for allowing stuff in the footer is that
it requires the complete entity body to be computed.
(Last-modified: fits if dynamic content takes an unknown but
significant ammount of time to be generated.)
I wouldn't allow Content-Type: in the footer because it would
then be difficult, to say, parse GIFs on the fly in a client,
or otherwise dispatch content-dependent software.
--
Albert Lunde Albert-Lunde@nwu.edu
Received on Friday, 5 September 1997 09:10:09 UTC