Re: Server-side roles in the HTTP

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)
?


> >   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 Wednesday, 1 September 1999 16:09:35 UTC