Re: Server-side roles in the HTTP

Mark wrote:
>
>Carl,
>
>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
>should
>> 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
>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.
>
>Intention here was more on the compress, deflate, gzip side than chunked.
>perhaps
>(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
>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.
>
>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.
>Suggestions?
>
>Thanks,
>
>
>

Received on Friday, 3 September 1999 22:42:41 UTC