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

Re: Server-side roles in the HTTP

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 2 Sep 1999 08:55:27 +1000
Message-ID: <015601bef4cd$1521eb10$0301a8c0@mnot.net>
To: <kugler@us.ibm.com>, <http-wg@cuckoo.hpl.hp.com>
Cc: <http-wg@hplb.hpl.hp.com>

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)

> >   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 00:06:46 UTC

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