W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1995

Re: Worries about content-length

From: David - Morris <dwm@shell.portal.com>
Date: Tue, 9 May 1995 18:35:18 -0700 (PDT)
To: http working group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Message-Id: <Pine.SUN.3.90.950509182521.7303D-100000@jobe.shell.portal.com>


On Tue, 9 May 1995, Paul Hoffman wrote:

> At 12:14 PM 5/9/95, David - Morris wrote:
> >For the subset of cases where the size isn't known
> >(e.g., CGI output), data could be delivered in a series of precisely
> >size computed chunks with the last chunk so marked.
> 
> I don't understand this at all. A CGI script delivers one chunk of output
> to the HTTP server software, which in turn pushes it out the designated
> port. Future CGI scripts *could* count characters before passing the chunk
> back, but I'm sure that few do this today. (Certainly none of the one's
> I've written do...)
> 
> It sounds like you want to force CGI scripts to measure their output so
> that the HTTP server software can add a correct length statement to the
> beginning of the output. If this is possible, it works fine, and will be
> 0.00000000000001% better than a pseudo-random string chosen by the HTTP
> server software to be the tail.

Actually, I mean to force servers to provide an accurate count.  The
CERN server offers the option today of computing content length. I don't
know about others.

The mention of 'chunck' is to allow for servers which may choose
to only cache part of the response. Chunk[n] with correct chunk length
would be sent when the first character of chunk[n+1] is received
OR the source closes w/o error.  If the CGI process or whatever
was generating the content aborts, then an abort chunk header would
be sent.

Receiving code can be simpler and more efficient if incoming data
doesn't require scanning to determine the length. Layered code 
won't need to kludge length determination in the SGML/HTML parser
to avoid multiple scans.  Etc.

Dave Morris
Received on Tuesday, 9 May 1995 18:36:37 EDT

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