Subject: Re: Server-side roles in the HTTP

From: [email-masked] (Julien Pierre)
Date: Thu, 02 Sep 1999 14:17:07 -0700

Hi,

[email-masked] wrote:

> If the full content is immediately available, it would be sent as one chunk.

Not necessarily.
It depends how the CGI is writing to stdout, on the OS, pipe buffer size, and on the
load on the machine.
If a dumb CGI writes one byte at a time to stdout, even in a tight loop, it's
possible that the kernel will make the daemon thread wake up and return it that
single byte, which would then be sent as a chunk if no buffer thresholds are set.
Every other 1-byte write may also result in another chunk. Some thresholds are
necessary to avoid those cases.

> >This won't work for some content generators.
> >For example, you can't start a CGI before you know the length of the POST data
> >because you have to set it in the CGI process environment variables.
>
> The one pathological case is CGI/1.1 and chunked POST requests.  Supposedly,
> future versions of CGI will deal with chunking.  And if the request provides
> Content-Length, you don't have to buffer it, even for CGI/1.1.

True - and we don't buffer the POST data in our daemon.

This reminds me of a case I was debugging a few weeks ago :
an echo CGI script writes the POST data to stdout as it comes, in a simple loop. The
problem is that most HTTP/1.0 clients send the full request first, then wait for the
server reply.

But if the POST data is large, at some point, the server's socket buffer gets full
when trying to send the reply, since the client isn't reading the reply yet (it's
still not done POSTing the request). At that point, both the clients and the server
are trying to send() and one of them times out (typically the server).

I haven't seen anything in the CGI spec that requires a script to first read all its
input before its starts writing to stdout. The script should be the proper place to
do the buffering for this case.

--
for a good time, try kill -9 -1

---

From: [email-masked]
Date: Thu, 02 Sep 1999 15:38:21 -0700

[email-masked] wrote: 
original article:http://www.egroups.com/group/http-wg/?start=8737
> necessary to avoid those cases.

Well, I just want to caution against optimizing for a pathological case
at the expense (e.g., reduced responsiveness) of normal cases.

Anyway, it's not that important anyway, since we're only talking about
the default behavior.  Mark's draft provides that:
   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.
So, if I don't want my responses buffered I can turn off buffering (in
theory).

    -Carl

---

From: [email-masked]
Date: Thu, 2 Sep 1999 09:51:40 -0600

jpierre wrote:
>
>
>Hi,
>
>[email-masked] wrote:
>
>> > 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?
>
>It depends on the size of the object and how long it takes to generate the
content.
>If the content is small and generated quickly, it makes sense for the server to
>buffer the response and transparently add a content-length header, as opposed
to
>using chunking. Chunking for small objects will waste bandwidth unnecessarily
and
>provide no benefits if the full content is immediately available.

If the full content is immediately available, it would be sent as one chunk.
How does that waste bandwith?   Let's see:  "Content-Length: xxxx" header, about
20 bytes; vs. "Transfer-Encoding:  chunked" header, about 27 bytes.  A
chunk-length and CRLF, say 6 bytes, and a 0,CRLF,CRLF terminator, say 5 more
bytes.  So we're looking at about 38 bytes of overhead vs. 20.   Is that
significant?

Chunking does provide benefits if the full content is not immediately available,
and adds (what I consider to be) an insignificant cost if it is not, so I think
it would be better to default to chunking instead of using a bunch of heuristics
to try to coalesce response content.

Either that, or provide a way for "content-producers" to control the
transfer-coding.

>If the application generates too much content to buffer, or ends up taking too
long
>to generate little content, then the server can choose to chunk.
>But this may be a matter for webmasters do decide depending on their
applications,
>how much bandwidth they have, and how much latency they can accept, so we are
making
>those time and buffer size thresholds configurable. We may also add settings
for the
>minimum size of the chunks themselves to conserve bandwidth.
>
>> > 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.
>
>Good point - looks like Mark should add a provision for this case.
>
>> 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.
>

> - jpierre.vcf
> - smime.p7s