World: r3wp

Ok, I'll try to hack the http-tools.r, see if I can get anything 
done. I saw a script written in python claiming to do multipart uploads, 
but I hope I can get it working in Rebol, which for me is always 
first choice.

Thanks everybody. I'll keep you posted.

what are you doing? still uploading binary? then use open/insert/close 
and change port to binary if it is open

hmm, does open/custom do that. i hope..

i guess i am on the wrong track..

I played with Oldes script a bit, didn't get far. I think there's 
no other option than follow Graham's advice and delve in the http 
scheme. I had hoped to find something in the script archive, oh well... 
I saw that even in the Ruby and Python community there's some confusion 
on how to achieve multipart form submissions with CGI. (Python default 
http library also uses  "application/x-www-form-urlencoded" and not 
""multipart/form-data", but there's a library called HTTPFileUploader 
that does the job). Last time I tried to hack the http scheme I wasn't 
so succesful. This time, if I need help, I'll ask for help.

do you need to write binary, or a multipart?could be multipart can 
use base64. then its somewhat bigger, but has no problems with text-mode. 
could even be that multipart of email works the same. in that case 
there is 'build-attach-body.

The script should be able to post a multipart form as described in 
rfc1867. It should be able to post a number of fields, for example: 
Content-Disposition: form-data; name="userid", and finally it should 
be able to upload a file in binary data.

Graham described what needs to be done (I used a variant of the http-tools.r 
script, composed the correct header, and then insert the headers, 
and then switched the port to binary before inserting the payload). 
Only it's a little a bit above my capacities. In other words, I'll 
need two weeks to do it, if I ever manage it.

Graham, I'm a big fan of http-tools.r (I believe you wrote it,right?). 
I used it in my DYNdns client that I wrote in Rebol. I realized only 
recently that some of the functionality was built-in.(Basic authenticaion 
with read/custom). Grrrr... if only you hadn't thrown those upload 
scripts away :)

Daniel, I wrote http-tools.r before there was a read/custom .. that's 
how old the script is!

Yeah, I remember some tips you contributed to the rebolzine on posting 
to web forms, way back... Anyway, I think I won't tinker with the 
http scheme, kinda dpressing thought, especially since I have great 
hopes to achieve what I need using curl and the shell capability 
of Rebol. Let curl do that work, afte r all, that's what' it's meant 
to do best.

I found the script .. written in 2002.

Undocumented .. but basically it took a directory of jpegs and zip 
files and uploaded them to a java based webserver that required custom 
headers

Great, can I see it?

And the good news is: curl does it flawlessly. I just saved myself 
two weeks of headaches. I am a reboller, but not a purist, if I find 
a better tool to do something, that's cool with me.

Sent.

Received. Thanks, indeed.

Anyone know the answer to this one? 

I have a cgi script that sends an email out. The problem is that 
I want to send to an address that has the same domain name as the 
website but whose mail server is not located there (It's an Exchange 
Server). Any other address works fine as expected. I think it has 
to do with the mx records but, the weird thing is that if I generate 
an email via php, it goes through. Therefore I'm thinking Rebol can 
do it too. 

I've used set-net  for the smtp server and have set it a different 
server completely but still no go.
And I'm in the process of having the MX records changed.

what is the trace/net say?

Oh, Haven't tried that. I'll see.

usually PHP uses the sendmail command directly, not SMTP, so it can't 
be compared unfortunately (ie the fact tha php can send mails does 
not guarantee that rebol can). but, you could use CALL and call sendmail 
directly too if there is no other option.

why not try using set-net [ email localhost ]

Thanks all. In the end I switched hosts and their mx records work 
so problem solved.

I mentioned the possibility (to overcome REBOL web-hosting) to place 
rebol executable directly in the /cgi-bin/ directory. Someone on 
ML mentioned I should not do that, security wise, as calling http://www.my-domain/cgi-bin/rebol
will spawn a process, which will run endlessly or so ...

I just wanted to ask - wasn't there some change in the past, to prevent 
such case? Would it be sufficient to rename rebol.exe to something 
like EDB433BDD7C13851C7C68CB31A5ACF33A80CD2CC? :-)

Or what about building special rebol version using SDK, running by 
default in cgi mode, quitting imediatelly, if there is not get or 
post string?

My understanding is the latter would be slower.  Also, QM (as an 
example) doesn't generally require a get query or post data (primarily 
uses path info).

petr, it is much better to just put rebol in another dir. there is 
no reason to have it in /cgi-bin/

aha, but can it be dir of my own site?

I mean - let's say I don't have telnet available - just ftp to upload 
my site ...

but even then, putting it in another dir, in order to be able to 
run rebol, I have to set it as runnable too, no? So what is the difference 
in having it in cgi-bin or other directory, if permissions have to 
be equal?

Pekr, well they don't have to. Script's permissons are different 
from some random visitor's permissions. Script is local and not remote.

the scripts have to be in cgi-bin, the interpreter can (and should) 
be somewhere else, where it is not accessible.

Gabriele - where it is not accessible? That means I need other then 
FTP access. That ruins easy REBOL deployment ...

why? ftp access only gives access to cgi-bin? usually, you have your 
own home dir, with www and cgi-bin dirs inside.

I'll check, but with hosting I have I seem to have root set to my 
web root.

So, in terms of my website, if I put rebol executable e.g. into /rebol/rebol.exe, 
is it any different security-wise to /cgi-bin/rebol.exe?

making rebol accessible is a security risk. i don't know of anything 
bad that you can make it do, but i'm sure it would not be too hard 
to make any interpreter do something bad if you allow it to be launched 
by anyone :)

yes, /rebol/rebol.exe will not be executed by the web server, unless 
it is specifically configured to do so.

if it's in cgi-bin, maybe i could do something like http://yoursite/cgi-bin/rebol?-s--do delete... 
etc.

hmm, then ice thing is, that when I run http://www.my-domain.com/cgi-bin/rebol
--do "print 123", Apache returns error, stating I have no permission 
to do that. If I run cgi-bin/rebol, my browser does not seem to return, 
so I expect interpreter to run infinitely?

(it shouldn't be that easy, but you get the idea)

hmm, woult there be an option to prepare special version of interpreter, 
using SDK, not allowing to accept any parameters, run only in CGI 
mode?

maybe, but is it really worth it? i don't think anyone would put 
perl in cgi-bin for eg. so why rebol?

because ppl endlessly complain, there are no rebol web-hosts. So 
I thought I might have universal solutoin. Just find yourself web-host, 
which allows cgi scripts, and you are done ...

I don't need it on my server, was trying to help other guys to not 
feel pressed from ISPs

afaik, any host that allows any cgi-bin will also allow you to upload 
rebol somewhere not in cgi-bin and then use it.

Any ISP that gives you FTP access to your account and CGI does provide

access for rebol