W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1999

Re: Server-side roles in the HTTP

From: <kugler@us.ibm.com>
Date: Thu, 2 Sep 1999 09:56:16 -0600
To: "Mark Nottingham" <mnot@mnot.net>
cc: http-wg@cuckoo.hpl.hp.com, http-wg@hplb.hpl.hp.com
Message-ID: <872567E0.0057C8D6.00@d53mta08h.boulder.ibm.com>

Mark wrote:
>Thanks for that. I should clarify in the draft that it's aimed at 1.1 AND
>1.0 connections (hence, buffering and so forth).
>> Why wouldn't streaming the response with the "chunked" encoding be
>preferable to
>> buffering and generating a Content-Length?  I don't think the server
>> attempt to buffer the response unless it's talking to an HTTP/1.0 client.
>That's what is intended; will clarify.
>> >   Servers SHOULD reply to requests that allow transfer encoding of
>> >  objects (i.e., TE header present) with appropriate encoding, in a
>> >  fashion transparent to the content generator.
>> This paragraphs seems to suggest that transfer encoding is only allowed if
>> TE request-header is present.  However, if the TE field-value is empty or
>if no
>> TE field is present, the transfer-coding "chunked" is allowed, and is
>> acceptable.
>Intention here was more on the compress, deflate, gzip side than chunked.
>(e.g., compression-related TE request headers)
>instead of
>(i.e., TE header present)

In that case, I think you want the "Accept-Encoding" header, not TE. (Make sure
you're looking at a fresh copy of the spec.)  The issue is of content-encoding
vs. transfer-encoding.

>> >   There MUST be a method by which content generators can specify that
>> >   content is not to be buffered; this MAY be performed by a pseudo-
>> >   HTTP header that is consumed by the server.
>> I think you're only addressing generated (response) content in this
>> I'd also like to have a method by which content generators can specify
>that the
>> received (request) content is not to be buffered.   Sometimes the "content
>> generator" can be doing something useful with the content of a large POST
>> request while it's still being received (or even while it's still being
>> generated by the client).  In some applications (e.g., IPP), POST content
>may be
>> so large that you don't even want the server to attempt to buffer it.
>Ah, interesting. yes, the request side would be good to put in there - will
>reread the IPP> chunked post messages.
>I hestiated to put in actual suggestions for buffering thresholds.
Received on Thursday, 2 September 1999 17:00:32 UTC

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