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