Re: Last-Modified in chunked footer

I can imagine wanting to put a Connection header-field in the footer
also, for example.  Or what if my ETag is based in part on a digest of
the entity?

Perhaps it would be better to build a list of header-fields explicitly
forbidden from the footer; that provides more rope but not quite as
much as opening it up completely.

There is another interesting vagueness in the spec related to this:
Does HEAD return the header-fields from the footer also?
I would say YES, but think that needs to be explicitly stated.

** Reply to note from Larry Masinter <> Thu, 4 Sep 1997 10:15:34 PDT
> > I agree with Jeff in that it is generally better to give people as
> > much rope as possible. Overly restricting legitimate applications is
> > far more of a hazard than making it possible for implementers to hang
> > themselves; after all, it's a lot easier for implementers to learn what
> > works (and what doesn't) than it is for us to go back and change the
> > definition of a header field.
> Removing the restriction on the sender unfortunately adds more
> complexity to the recipient, if the recipient must be able to
> process mandatory header-fields in the trailer. And implementors
> of recipients and senders seem to be in different groups, even
> if they work for the same company, so we can't rely on implementor
> ingenuity to get this one 'right'.
> I was thinking of something like:
> "Any header-field which the sender MUST send in a request should be
> in the header and not in the trailer."
> although that is not quite right.
> (I will note, parenthetically, that the ability to say the previous
> sentence is critically dependent on separating "header-field" from
> "header".)
> Larry
> -- 

Richard L. Gray
chocolate - the One True food group

Received on Friday, 5 September 1997 07:46:05 UTC