World: r3wp

Yes, the most recent version is newer httpd service which is called 
Cheynne :)

and do we have access to that httpd source? Cheyenne is encapped, 
no?

Yes, the encapped part is the httpd service. You can see, that in 
Cheynne archive there is a little bit newer uniserve engine - 0.9.20

(not just httpd as it is able to do for example bzip2 compression 
so it probably needs some libs)

ech.. no, the compression should be in version 1.0

and if you look into cgi code in the UniServe archive, you can see, 
it identifies itself like soc/server-software: "Cheyenne/1.0"

so what is here is Cheyenne in some unfinished state

hmm.... maybe if someone was using uniserver 0.9.9 and want to upgrade, 
there was important change - instead of module/response there is 
now module/result

but 0.919 is provided with no documentation ... what is the difference 
then?

so the project - moving forward - contains encapped modules?

This was quite important difference as my scripts were still using 
response (so I was getting result = none)

I'm slowly moving forward:) after a few hours I almost have what 
I already had but using new uniserve:)

so new version, 0919 does not work s is?

it works, but you have to do some small changes:-)

as the one above

and I'm not using most of the files. (At least now)

I've got this newer Nenad's version of UniServe http://box.lebeda.ws/~hmm/rebol/UniServe-r0991.zip
(but as he said - beware, it needs several fixes and updates to become 
a 1.0 candidate)

he is in contact with you?

btw - what fixes it needs?

Yes, we had a short electronic contact :-) In this archive are the 
proxy and httpd services working without need of changes, the cgi 
test seems to give me an error so probably this will need some fix.

is Doc going to be back on Uniserve or Chayanne? Without fixed sessions 
it is mostly non working httpd server

Do you mean that sessions are non-working, or that there is something 
about non-working sessions that makes HTTP (a stateless protocol 
that wouldn't normally need sessions) not work?

I don't know what is with sessions. The uniserve seems to pretty 
good to me. I'm using it. And I think that Doc is still Reboling, 
probably just don't have so much time.

BrianH - of course if you don't need sessions, httpd is probably 
working well. I just did not understand the Cheyenne release. The 
simple demo did not work. There is a demo with screen divided into 
something like 4x4 subwindows (frames), and most of them times out. 
Doc told me session layer is about to be rewritten, then no word 
from him for another few months

Surely you are not surprised that Doc would disappear abruptly? He 
seems to have even less time than I do.

there is file %libs/cookies.r so one can take a look at it, if needed

the chayenne is just encrypted uniserve

You mean HTTPS?

I don't know how it's with https, I don't have /command

I don't know how it would have HTTPS server support, even with /Command. 
I thought /Command only has SSL client support.

well, command can read https pages...?

ok... doc' seems to be online now, as he emailed me almost immediately:


I'm aware of this problem (cgi and paths). It's because the encap-fs 
system is not 

correctly supported in this version of UniServe (it's ok in the Cheyenne 

package). I didn't fixed it because, with the release of Cheyenne, 
I'm 

not sure to keep the CGI support for the HTTPd service in the UniServe 

package. I may just provide a static HTTPd server with hooks to extend 

it or embed it in user applications. v1 of UniServe have to be very 
easy 
to embed in any app (that's one of main goals).

Reading is client-side SSL.

Sessions are broken in cheyenne.  Basically session data from one 
client ends up as session data in another :(

Rebol can't do server side SSL ... Carl thought it could by changing 
a flag, but it does not work when it was tested.

So, without server side SSL, Cheyenne can't do https .. unless it's 
thru stunnel.

Rebol can't do server side SSL
 - close but no cigar, actually, it is not that hard

let me rephrase that .. no one outside of RT and their contractors 
know how to do this.

close but no cigar again

:-)

(you can implement it in REBOL)

all the actual core needs are within... its just a question of reading 
the rfc (or implementation guides, or books) and using the encryptions 
funcs within REBOL...  but I'll agree its not for the faint of heart... 
I've read a lot about server-side ssl implemtation a few months ago 
and its quite laborious.  But still doable.

do i smell a competition?

If I had time I would have done it much before, but we ended up using 
apache and a reverse proxy setup... and that works really well.

it also allows us to spread connections over many machines/threads 
virtualise the port and all that nice stuff without actually having 
to code it.

(and apache is good at handling thousands of requests without crashing)

Must say, that I'm all day using the proxy service from the latest 
uniserve and have no problems with it. It's fast enough even when 
streaming videos:) It's quite fun to watch what files are transfered 
while surfing.

hum... uniserve can work as a proxy  ?

yes, and it's the best Rebol proxy I used. Just:
uniserve/boot/with [services [proxy-http] protocols [http]]

The source is in %services/proxy-http.r