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

Re: Last-Modified in chunked footer

From: Klaus Weide <kweide@tezcat.com>
Date: Wed, 3 Sep 1997 16:57:04 -0500 (CDT)
To: rlgray@raleigh.ibm.com
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.SUN.3.95.970903163547.29138C-100000@xochi.tezcat.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4297
On Wed, 3 Sep 1997 rlgray@raleigh.ibm.com wrote:

> First you argue that we cannot hurt the clients to benefit the servers.
> Now you claim we must benefit the clients at the cost of the servers.
> You cannot have it both ways.

Your second sentence doesn't seem to describe anything I have written.
Can you point me to where I say that?

> As John Franks says, the choice is NO l-m or l-m at the end.
> If you do not want to see it in the footer, you can ignore it and it
> will be as if it was not sent.
> I have to calculate l-m correctly or not send it or my customers
> will complain about the page not being refreshed on reload after a
> change in a component document.

So if allowing l-m in footers is a good thing, it should be explicitly
allowed there.  I have no opinion on that, but don't see a reason
why it should not be done.

Allowing _all_ headers (or all end-to-end headers) to appear in footers
unless specifically forbidden is quite a different matter.

> I think that relaxing the restriction will benefit everyone.
> ** Reply to note from Klaus Weide <kweide@tezcat.com> Wed, 3 Sep 1997 16:06:07 -0500 (CDT)
> > I believe the MUST should stay as it is, for the benefit of clients, 
> > except for specific headers as it is now.  I am not arguing against
> > adding any specific headers (like the ones proposed) to the list of 
> > those allowed in footers, just against changing the default rule.

I though that last sentence made it clear that I was not speaking against
allowing l-m in footers.  Maybe my writing was unclear, wouldn't be the
first time. :)

Received on Wednesday, 3 September 1997 14:59:32 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:03 UTC