RE: Last-Modified in chunked footer

So Spake Klaus:
>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.

Amen.
	Yaron

> -----Original Message-----
> From:	Klaus Weide [SMTP:kweide@tezcat.com]
> Sent:	Friday, September 05, 1997 12:57 PM
> To:	Maurizio Codogno
> Cc:	http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> Subject:	Re: Last-Modified in chunked footer
> 
> 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
>