Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[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-