Syntax for POST processing via CGI?

[Jim Ault]

A multi-part form is a MIME type of format that does require boundary
strings that are unique and would not be confused with data.  I have seen
some messages where the Boundary is defined early on, then used later.

The result is that data parts are clearly delimited and each has its own set
of headers so mixed data types can be sent in a single upload event.

The format of the POST (which becomes the "stdin" variable in the CGI memory
space) depends on the sending program.  The GET form allows name=variable&
pairs, but only works for about 1100 chars, is sent in the clear, and can be
hijacked by any one.  The POST form of packaging data has no size limit, can
be any string of characters (such as the multi-part form data), is hidden,
plus is not easily hijacked.

(By hijacking I mean sending data to your server that would cause problems
or security issues)
An example would be
http://map.gov/colormap.php?country=US&location=missiles&resolution=high
--thus you create your own string

Jim Ault
Las Vegas

On 1/10/09 12:21 PM, "Mark Smith" <lists at futilism.com> wrote:

> Bill, that looks like multi-part form data. I'm not very up on that,
> but I think the numbers at the start of each part do have some
> significance.
> 
> Maybe Dave or Andre can chip in here? Anyone?
> 
> best,
> 
> Mark
> 
> On 10 Jan 2009, at 17:52, Bill Marriott wrote:
> 
>> Thanks so much, Mark!
>> 
>> That worked; much easier than I thought... though the return from
>> stdin is
>> more like:
>> 
>>> -----------------------------7d92ce191e091a
>>> Content-Disposition: form-data; name="FirstName"
>>> 
>>> Bill
>> 
>> and not the value/parameter pairs you get from a GET. I wonder what
>> the
>> number in the first line signifies (it's not the value specified in
>> the
>> $UNIQUE_ID global).
>> 
>> It's interesting how a binary upload is handled... I get:
>> 
>>> -----------------------------7d92ce191e091a
>>> Content-Disposition: form-data; name="FileUpload"; filename=""
>>> Content-Type: application/octet-stream
>> 
>> followed by a variety of stuff depending on what kind of document I've
>> submitted. It doesn't look like it's Mime (or Base64 encoded), and
>> it's
>> nowhere near the full number of bytes in the file. I might also
>> note that
>> uploading is considerably slower than, say, PHP -- a 20K JPG took
>> more than
>> two minutes. Is this something to do with the way the data is being
>> read?
>> 
>> What's the magic in handling a file upload? (Again, bare-bones.)
>> 
>> FWIW I think I'll put this together in an article for the next revUp
>> newsletter.
>> 
>> - Bill
>> 
>> "Mark Smith" wrote:
>> 
>>> on startup
>>>    put postData() into tPostData
>>>    split tPostData by "&" & "="
>>>    -- postData is now an array of the form data
>>> 
>>> end startup
>>> 
>>> function postData
>>>    put empty into tData
>>>    put 0 into c
>>>    repeat while tData is empty and c < 20
>>>       read from stdin until empty
>>>       put it after tData
>>>       add 1 to c
>>>       wait 20 millisecs
>>>    end repeat
>>>    return tData
>>> end postData
>>> 
>>> 
>>> note that it reads from stdin repeatedly until it's got something
>>> -  for
>>> some reason, the data doesn't always appear straight away.
>>> 
>>> On 10 Jan 2009, at 14:42, Bill Marriott wrote:
>>> 
>>>> anyone have a
>>>> bare-bones script for processing POST submissions with CGI
>> 
>> 
>> 
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution