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: Thu, 4 Sep 1997 13:37:14 -0500 (CDT)
To: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.SUN.3.95.970904131940.29138F-100000@xochi.tezcat.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4318
On Wed, 3 Sep 1997, Roy T. Fielding wrote:

> >How about turning that around?  I.e., instead of prohibiting what
> >is not explicitly allowed, as we do today, we should allow what
> >is not explicitly prohibited.  So, I would say "if putting the
> >header in the trailer makes it too late to be useful, then we should
> >prohibit that."
> 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.

The question is, will they just hang themselves with that rope, or will
they hang others or acceptance of the protocol.

In a previous exchange in the RE-VERSION thread, IIRC you argued that
there was no good reason for a 1.1 client to insist on not receiving
chunked, since the implementation was simple. (please correct me if my
memory is wrong.)  If some dynamic services start sending essential
headers (which the client needs) in footers because it is easier to
implement, which they would otherwise send before the body, user agent
implementers will have a good reason to ask "How can I turn this off".
Or to just not implement 1.1 and stay 1.0.

Or are 1.1 user agents free to ignore any headers that come "too late",
would they still be conformant?

Received on Thursday, 4 September 1997 11:43:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:28 UTC