Thanks a ton, [EMAIL PROTECTED] Poring over the code in the Aloha server is just too much work, but just your mention of 'multipart/form-data' send me rocketing in the right direction (I was screwing around fruitlessly with force_input() when I got your response). With a little googling about HTTP protocol, I have now got E_WEB seeing the POST results ... although the parsing work that will go into dissecting the multipart enclosures more tedious, it's no biggie. And the best thing is: the very last line of a multipart enclosure, unlike the last line of a standard POST reply body, *is* terminated by a CR/LF, rendering the total number of bytes successfully received by E_WEB consistent with the 'Content-Length' header, so with nothing orphaned in the buffer I can keep an accurate count and tell E_WEB when to stop reading.
Love this list ... thanks again! --- "[EMAIL PROTECTED]" wrote: > > using multipart-form data seems to work good for POST. > have a look at the codes of Aloha (http://moo.kcc.hawaii.edu/aloha) > rv, > > > Hi all, > > > > I have been unable in the past to get the implementation of the > HTTP > > 'POST' method working on E_WEB in LambaMOO 1.8.1 ... so I relied > on > > accepting forms via 'GET' instead. Well, now I am coding a form > with > > so much info that it exceeds Internet Explorer's 2048-byte limit > on > > the length of a URL. I *have* to use POST. So I used a > packet-sniffer > > and debug routines to figure out where E_WEB is hanging ... and I > > think I understand why, but I don't have a solution. > > > > When I send a form via the 'POST' method in both Camino and > Safari on > > the Mac, the final line of the HTTP request is passed > unterminated by > > a CR or LF ... and unfortunately this line contains all of the > > relevant POST data generated by the form. But E_WEB uses the > read() > > function to read the web request, and as far as I can tell, > read() > > will not return any info without a carriage return, so E_WEB gets > > hung at the very end of the request waiting for the data to be > > terminated. > > > > Here's what the POST request sends, as revealed by a packet > sniffer > > ... I have omitted the URLs involved for privacy, and added the > > carriage returns and linefeeds ("[CR/LF]") that are invisible in > the > > text file: > > > > POST /1333/ HTTP/1.1[CR/LF] > > Host: [omitted][CR/LF] > > User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; > en-US; > > rv:1.7) Gecko/20040623 Camino/0.8[CR/LF] > > Accept: > > > text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5[CR/LF] > > Accept-Language: en-us,en;q=0.5[CR/LF] > > Accept-Encoding: gzip,deflate[CR/LF] > > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7[CR/LF] > > Keep-Alive: 300[CR/LF] > > Connection: keep-alive[CR/LF] > > Referer: [omitted][CR/LF] > > Content-Type: application/x-www-form-urlencoded[CR/LF] > > Content-Length: 28[CR/LF] > > [CR/LF] > > flip=Data1&write=Data2&Submit=Post > > > > Notice that the final line, which contains the data I need, is > > unterminated. When I hack the E_WEB server to notify me of every > line > > it receives, I get the following literals... > > > > {"POST /1333/lx1840/post/ HTTP/1.1"} > > {"Host: books.that.dontexist.dnsalias.net:8900"} > > {"User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; > en-US; > > rv:1.7) Gecko/20040623 Camino/0.8"} > > {"Accept: > > > text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5"} > > {"Accept-Language: en-us,en;q=0.5"} > > {"Accept-Encoding: gzip,deflate"} > > {"Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7"} > > {"Keep-Alive: 300"} > > {"Connection: keep-alive"} > > {"Referer: http://that.dontexist.dnsalias.net:8900/1333"} > > {"Content-Type: application/x-www-form-urlencoded"} > > {"Content-Length: 28"} > > {""} > > > > And there the loop hangs ... presumably waiting for the final > line to > > be terminated. Most web servers don't need the termination, since > > they use the preceding 'Content-Length' header as a cue to when > to > > stop reading. As far as I can see, there is no way to implement > this > > behaviour in MOO code. Or is there something I have overlooked? > Is > > there a way that I can read a single character off of a > connection at > > a time? If there is, E_WEB doesn't use it, and I don't understand > why > > the programmers of E_WEB expected their POST routine to work. > > > > Thanks in advance for any help you could provide. > > > > Paul. > > > > > > > ______________________________________________________________________ > > Post your free ad now! http://personals.yahoo.ca > > > > ############################################################# > > This message is sent to you because you are subscribed to > > the mailing list <moo-cows@the-b.org>. > > To unsubscribe, E-mail to: <[EMAIL PROTECTED]> > > To switch to the DIGEST mode, E-mail to > <[EMAIL PROTECTED]> > > To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> > > Send administrative queries to <[EMAIL PROTECTED]> > > > > > > ------BEGIN GC BLOCK----- > GO d? s-:-- !a C++ L++ P++ L++ E- W-- N+ o K- w--- !O M !V > PS+++ !PE Y+ PGP t !5 X R* !tv b+ !DI D- G e+++ h !r y? > ------END GC BLOCK------ > ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca ############################################################# This message is sent to you because you are subscribed to the mailing list <moo-cows@the-b.org>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
