[REBOL] Re: read bug?
From: joel:neely:fedex at: 2-May-2001 8:13
Carl Sassenrath wrote:
> I know of no such buffer limit. Generally speaking, REBOL
> uses expandable series for just about everything. If there
> is a buffer limit, then it's quite by accident somewhere,
> and we should track it down.
>
A few months back I posted to the list a collection of tests
I had performed with various ways to try to obtain the user
data posted by a form. I encountered the problem trying to
use Andrew Grossman's wiki.r script as a quick-and-dirty
project notebook. The relevant portion of that script is
8<------------------------------------------------------------
if system/options/cgi/request-method = "GET" [
do decode-cgi system/options/cgi/query-string]
if system/options/cgi/request-method = "POST" [
post: make string! input do decode-cgi post]
8<------------------------------------------------------------
The call to INPUT only gets a portion of the input if the user
has typed more than a certain amount of data into the text area
of the original form. This constrasts with the behavior of
READ which gives you all of the data from its source, regardless
of length. The tests I posted (late November of last year)
documented a variety of attempted workarounds. I'll be glad to
try to locate that original post and resubmit, but can't do it
at the moment.
> Also, have you tried using read/custom with POST data
> as described in the manual? It allows you to keep the
> POST data out of the URL and put it into the body of
> the http packet where it belongs. Much better for large
> amounts of data, for example if you wanted to post an
> image or file or large REBOL block.
>
I'll be happy to stand corrected if I'm wrong, but I looked
at the manual again just to be sure... It appears to me that
READ/CUSTOM has to do with *sending* the POST data from client
side to the server. What I thought we were dealing with in
this thread was the problem of *receiving* long POST data on
the server side. At least that's what I was referring to in
my comments...
> The reason that CGI uses the REBOL CGI object with all of its
> fields is to make it similar to standard CGI interface
> found on most systems.
>
No offense, but... ;-)
The details of writing an FTP client are a bit complicated on
most systems, but REBOL abstracts away from all that complexity
and lets me say
read ftp://my.server.com/foo/gorp.data
without all the complexity. I had thought that similarly
abstracting away from implementation details to give a tidier
way to write CGI scripts would be The REBOL Way.
The REBOL CGI interface is far more cumbersome to use than
(for example) the Perl CGI interface. In that interface:
1) The param() function with no arguments gives back a
hash containing all form parameters (e.g. a block! of
key/value pairs or an object!).
2) All other relevant knowledge (headers, etc.) are in the
environment hash, keyed by the header field name.
This is not optimal, but is easy to keep straight because
all user data are available via param() and everything else
(system and protocol data) are available in %ENV .
OTOH, I haven't yet figured out a simple scheme for keeping
up with which data are top-level in SYSTEM/OPTIONS/CGI and
which have to be looked up in SYSTEM/OPTIONS/CGI/OTHER-HEADERS
Of course, this is relatively minor compared to the differences
in handling GET vs. POST, which the Perl CGI interface renders
completely invisible.
Again, please let me stress that all of these comments are in
the context of my overall high regard and appreciation for
REBOL, yourself, and your entire team. I wouldn't be whining
about the fabric on the seat covers if the engine and gearbox
weren't working so wonderfully well! ;-)
-jn-