- From: Klaus Weide <kweide@tezcat.com>
- Date: Fri, 5 Sep 1997 14:57:04 -0500 (CDT)
- To: Maurizio Codogno <mau@beatles.cselt.it>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Fri, 5 Sep 1997, Maurizio Codogno wrote: > Speaking seriously: > Would it be useful to use a placeholder like (atend) in PostScript > so that we can say "if a header can be calculated only after the > entity body has been served, the server SHOULD use a header > of the form > <header-line> : (atend) > and repeat the header line with the correct value after the body", > or it's just a useless burden? I was thinking of something similar, a `Delayed-Header' or `See-Footer' header that would list the names of header-fields which may be sent after the body: Delayed-Header: last-modified, content-language A client would then be alerted to the fact that it hasn't seen all the header fields, and at least avoid drawing wrong conclusions from the absense of a header field. If headers-in-footer is made "wide-open", including headers not yet invented, then to make it useful in an interoperable way there should also be a specification how "late headers" are to be combined with "early headers". Is it an error if a header field appears in a footer when a header filed with the same name was in the "early headers", or do "late headers" override all "early headers" with the same name, or do the values get appended (in the case where field-value is defined as #(values)) ? However, I think it is too late to introduce such new protocol features into the main HTTP 1.1 spec at this stage. The formulation could be changed so that such extensions (by future protocols, "by mutual agreement" etc.) are not forbidden, but no specific behavior is required for HTTP 1.1 clients. Klaus
Received on Friday, 5 September 1997 13:00:00 UTC