- From: Roy T. Fielding <fielding@liege.ICS.UCI.EDU>
- Date: Sat, 01 Jun 1996 02:47:05 -0700
- To: Paul Leach <paulle@microsoft.com>
- Cc: "'http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com'" <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
> Section 3.6 on chunked transfer-coding says
> footer = *Entity-Header
>
> This used to say something like
>
> footer = *<Content-MD5 or future headers that explicitly state that
> they
> can be in footers>
>
> This was because of a previous objection (by whom I don't recall) that
> they didn't want to have to make sure their implementation handled
> arbitrary headers (especially ones like Content-Type that might affect
> how the entity was processed) after the entity-body had been received. I
> hypothesize that this is because the current implementations alwys have
> all the existing headers in hand before the entity-body starts arriving,
> and might be difficult to change. In any case, there seems to be little
> advantage in allowing arbitrary headers in the footer, and allowing them
> runs counter to the pupose for them stated in the text of the section;
> the proposed change to the BNF merely tries to capture that intent.
The BNF describes the SYNTAX of HTTP, not the policy. It is inappropriate
to require an application to know about the SYNTAX of "future headers that
explicitly state they can be in footers". Therefore, it must not be in
the BNF. The BNF should be
footer = *Entity-Header
and be immediately followed by a policy requirement:
Applications MUST NOT send header fields in the footer which are
not explicitly defined as being appropriate for a footer, as is
the case for Content-MD5 (section ...).
...Roy T. Fielding
Department of Information & Computer Science (fielding@ics.uci.edu)
University of California, Irvine, CA 92717-3425 fax:+1(714)824-4056
http://www.ics.uci.edu/~fielding/
Received on Saturday, 1 June 1996 02:54:10 UTC