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

am I losing it with webserv.r?

 [1/8] from: eric:ehrichweiss at: 8-Jun-2005 17:49


Ok, Ammon has been helping me as much as possible and so has Cal Dixon but I have to know... Is anyone using webserv.r with Vanilla 0.6 and successfully getting files uploaded? This mostly boils down to me not being able to get any POST http data to work with webserv but Vanilla is standard enough that I figure that if it is not working with webserv, then maybe it's not just my scripts. Thanks Eric

 [2/8] from: andreas::bolka::gmx::net at: 10-Jun-2005 1:44


Wednesday, June 8, 2005, 11:49:46 PM, Eric wrote:
> Ammon has been helping me as much as possible and so has Cal Dixon > but I have to know... Is anyone using webserv.r with Vanilla 0.6 and > successfully getting files uploaded? This mostly boils down to me > not being able to get any POST http data to work with webserv but > Vanilla is standard enough that I figure that if it is not working > with webserv, then maybe it's not just my scripts.
using webserv.r 0.0.0.15 which i downloaded just this very moment from the script library, it seems that POST's get not handled very well. i use a very simple upload.cgi: REBOL [] print "Content-type: text/plain^/" print "hello world!" probe system/options/cgi and an even simpler upload.html: <form enctype="multipart/form-data" action="upload.cgi" method="POST"> <input type="file" name="nuf" /> <input type="submit" /> </form> when i submit something via this form, i see an entry in the log: 127.0.0.1 - - [10/Jun/2005:1:35:37+2:00] "POST /upload.cgi HTTP/1.1" 200 1272 ... but my browser responds with "this document contains no data". so it seems something within webserv.r does not handle POSTs very well. sorry, i'm currently in a kind of hurry, so i might have made a very trivial mistake here. if not, something very fundamental seems to be bugged. -- Best regards, Andreas

 [3/8] from: eric:ehrichweiss at: 9-Jun-2005 19:55


Andreas Bolka wrote:
> using webserv.r 0.0.0.15 which i downloaded just this very moment from > the script library, it seems that POST's get not handled very well. i
<<quoted lines omitted: 16>>
> trivial mistake here. if not, something very fundamental seems to be > bugged.
Nope, you're getting exactly what I'm getting and I wish I understood what the fix was. My scripts work fine with Apache and the like but fail with webserv. Cal suggested a few ideas but I never could get any of them to work. Of course if I could understand what he is doing with system/ports/input and system/ports/output a little better, I might be able to fix it myself...no luck so far though.

 [4/8] from: volker::nitsch::gmail::com at: 10-Jun-2005 23:53


On 6/10/05, Eric Haddix <[eric--ehrichweiss--com]> wrote:
> Andreas Bolka wrote: > > using webserv.r 0.0.0.15 which i downloaded just this very moment from
<<quoted lines omitted: 10>>
> > > > <form enctype="multipart/form-data" action="upload.cgi" method==
POST
> > <input type="file" name="nuf" /> > > <input type="submit" />
<<quoted lines omitted: 18>>
> able to fix it myself...no luck so far though. > --
Looking in my somewhat patched version: try behind insert tail script-cache reduce [file-path script] this set-modes system/ports/input [lines: false no-wait: false] (or put it in your own script) then use copy/part system/ports/input system/options/cgi/content-length instead of the "official" read-io loop. (AFAIK vanilla does that too) Hope that works -- -Volker Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem. David Wheeler

 [5/8] from: Izkata::Comcast::net at: 10-Jun-2005 14:35


I use a modified Micro Webserver for all of my experimenting, and have never needed to use CGI, but perhaps this can be of a little help: http-port: first wait listen-port Data: copy http-port/state/inBuffer ;Here's your POST data Looks like this line in your Webserv.r is what you want: if error? try [ request: parse first (conn: first listen) none ] [ close conn return ] Add this line after it... I think it's what you want.. POSTData: copy conn/state/inBuffer

 [6/8] from: eric::ehrichweiss::com at: 11-Jun-2005 16:53


Ok, I tried your suggestion and I got it to work somewhat but only after I decided to start debugging even more... I added: POSTData: copy conn/state/inBuffer as you stated and it didn't work so right after it I put write/binary %/c/test1 POSTData to see what it was getting and then for some strange reason vanilla started taking the uploads but only sporadically. I really want someone to explain why writing the info in POSTData to a file causes it to work. I do know that POSTData doesn't contain the actual data but instead the http headers, etc. which confuses me even more but I digress. If I uploaded a file(or even several) and then went to another page, coming back to the "vanilla-attach" got me a blank page. I'm still working on that one but I'm going to simply see if I can use it with MY scripts which will require much less than vanilla does. If anyone has any insight..I'm all ears... Eric Izkata wrote:

 [7/8] from: Izkata::Comcast::net at: 11-Jun-2005 20:39


Yey - glad I could help =^) Instead of inBuffer, you may also want to check one of the other values of the 'state object:
>> A: open tcp://:889 ;just really quick to see the values >> probe A/state
make object! [ flags: 4719107 misc: [224 [] 0] tail: 0 num: 0 with: "^/" custom: none index: 0 func: 6 fpos: 0 inBuffer: none outBuffer: none ] Honestly, I have no idea what any of the others are for... Just inBuffer... -Izzy Boy

 [8/8] from: andreas:bolka:gmx at: 12-Jun-2005 4:07


Saturday, June 11, 2005, 10:53:33 PM, Eric wrote:
> and then for some strange reason vanilla started taking the uploads > but only sporadically. I really want someone
interesting. after a bit of debugging i didnt even get a simple POST to a simple cgi working. when i commented out the last close conn in handle-cgi and added a content-length header to the output of the result, it somehow started to work. ensuring that the modes [no-wait: true direct: true binary: true] are set did not help. i then got fed up and stopped working on that ;) i concluded that something handling HTTP POST either within webserv.r or firefox is severely broken. -- Best regards, Andreas

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted