W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

Re: Last-Modified in chunked footer

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
Message-Id: <Pine.SUN.3.95.970905135307.1298J-100000@xochi.tezcat.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 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:00 EDT