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: Wed, 1 Sep 1999 13:36:00 -0600
cc: http-wg@hplb.hpl.hp.com
Message-ID: <872567DF.006BE597.00@d53mta08h.boulder.ibm.com>


> Servers MUST support a persistent connection if the content
>   generator supplies a Content-Length header. If it is not available,
>  the server SHOULD attempt to buffer the response in order to
>   generate one, although this MAY be circumvented if:
>   * the server does not have resources (i.e., memory) to do so, or
>   * the object is very large, and overall latency becomes
>   unacceptable, or
>   * the time required to generate the object adds unacceptable latency
...
>  Servers MUST serve chunked encoding responses for all objects, if:
>   * Content-Length is unavailable and impractical to generate
>   and
>   * the client advertises itself as HTTP/1.1 capable, or
>   * the client includes 'chunked' in a TE header

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 should
attempt to buffer the response unless it's talking to an HTTP/1.0 client.

> 6.4 Transfer-Encoding

>   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 the
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 always
acceptable.

>   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 statement.
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.

     -Carl Kugler
Received on Wednesday, 1 September 1999 20:39:57 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:33 EDT