Adam Warner <usenet@consulting.net.nz> wrote:
+---------------
| In CGI programming data being POSTed is sent to the CGI program via the
| terminal. It would be ideal to read this data in one step into a sequence
| using read-sequence. But unlike a file on a hard disk there appears to be
| no way to determine the size of the data. We conceptually know it is a
| block of data produced by one web request. But I know of no way to find
| out the size of that data so I can first set the size of the vector.
+---------------
Read RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
<URL:ftp://ftp.isi.edu/in-notes/rfc2616.txt>:
4.3 Message Body
...
The presence of a message-body in a request is signaled by the
inclusion of a Content-Length or Transfer-Encoding header field
in the request's message-headers.
...
4.4 Message Length
...
When a message-body is included with a message, the transfer-length
of that body is determined by one of the following (in order of
precedence):
1. Any response message which "MUST NOT" include a message-body...
2. ...Transfer-Encoding header field... [e.g., "chunked" encoding,
which carries a length marker pre chunk]
3. ...Content-Length header field...
4. If the message uses the media type "multipart/byteranges",
and the transfer-length is not otherwise specified, then
this self-delimiting media type defines the transfer-length.
5. By the server closing the connection. (Closing the connection
cannot be used to indicate the end of a request body, since
that would leave no possibility for the server to send back
a response.)
...
7.2.2 Entity Length
The entity-length of a message is the length of the message-body
before any transfer-codings have been applied. Section 4.4 defines
how the transfer-length of a message-body is determined.
...
9.5 POST
The POST method is used to request that the origin server accept
the entity enclosed in the request...
That is, the client side is *required* to send the length -- in some form
or another, whether Content-Length, chunked transfers, or byteranges --
for any entity (message body) it sends with a "POST". If the client uses
Content-Length, then you know *before* you start reading the data exactly
how long it is. If it uses chunked or byteranges, you at least know how
big each chunk or ramge is before reading it (and may need to concatentate
them later).
If your server is not prepared to deal with the full generality of
HTTP/1.1 chunks/ranges, you might want to consider having it declare
itself as an HTTP/1.0 server, in which case:
<URL:ftp://ftp.isi.edu/in-notes/rfc1945.txt>
...
8.3 POST
A valid Content-Length is required on all HTTP/1.0 POST
requests. An HTTP/1.0 server should respond with a 400
(bad request) message if it cannot determine the length
of the request message's content.
Almost all clients these days will still send an HTTP/1.1 "Host:" header
even when talking to an HTTP/1.0 server, which still allows virtual
domains (virutal servers) to work, so don't let that bother you too much.
Or if your CL program isn't the server itself, but is running via
CGI under some other server (such as Apache), then AFAIK that server
is required to "gather up" any chunked input and present it to you
in a single blob, the same way an HTTP/1.0 server would, with the
"CONTENT_LENGTH" environment variable set to the entity length.
[The CL implementation you're using *does* provide some way to get
at the CGI-mandated <URL:http://hoohoo.ncsa.uiuc.edu/cgi/env.html>
environment variables, yes?]
+---------------
| If read-sequence would just auto-extend the vector this would not be
| a problem.
+---------------
You don't need this. As noted above, the client is required to tell
you how big the data is.
-Rob
-----
Rob Warnock, PP-ASEL-IA <rpw3@rpw3.org>
627 26th Avenue <URL:http://www.rpw3.org/>
San Mateo, CA 94403 (650)572-2607