World: r3wp

ssl is just as easy.

Terry, in theory, it should be possible to reload the module code 
while the server is running, in practice, the internal framework 
is lacking a few functions to allow you to do that. Maybe I should 
make such feature available through the RConsole service (thinking 
loud).

SSL support, currently the only way to support SSL for Cheyenne is 
sTunnel.

A method to distinguish between SSL request (coming from stunnel) 
or normal HTTP request, is to make Cheyenne listens on 2 ports : 
80 and 443 (for example, could be any port <> 80) and configure stunnel 
to redirect the decrypted SSL traffic to port 443. Then in your RSP, 
request/server-port will tell which port was used to receive the 
request. Example :

switch request/server-port [
	80  [...normal HTTP traffic...]
	443 [...SSL traffic...]
]

need to be careful not to allow users to access http://yourhost:443 
though :)

sure ;-)

maybe it would be a good idea to not use 443 but, e.g., 10443 and 
make sure to have a firewall rule blocking 10443 from outside.

if you want to experiment with such configuration, you need to change 
a few lines in cheyenne.r to make it listen on 2 ports. This is the 
procedure :

In %cheyenne.r, replace the following line :

    uniserve/boot/with []
    
by :

    uniserve/boot/with/no-loop []
    uniserve/control/start 'HTTPd 10443
    do-events

You could instantiate as much HTTPd server as you want by duplicating 
the uniserve/control/start line. Btw, you can do that with any UniServe 
services while your server is running through RConsole ;-)

If you can't block the traffic from outside using firewall rules, 
you can reject connections on port 10443 from within the HTTPd service 
by overloading the 'on-new-client callback and adding a check like 
this :

if all [
	client/local-port = 10443
	client/remote-ip <> 127.0.0.1
][
	close-client
	exit
]


This wouldn't be as efficient and secure as using a firewall, but 
should be suitable for most cases.

What is the problem with localhost:443 you describe?

If Stunnel listens on that port, it simply redirects traffic to your 
uniserve egnine, which listens on different port, no?

right, in fact, you could not make Cheyenne listen on 443 is stunnel 
is already running (because it will already use it).

that is my point .... but I am not strong with security issues, so, 
I better asked :-)

is stunnel => if stunnel

so you simulate https via stunnel? Does it work? I thought that Stunnel 
is mainly to create VPNs, so that you need stunnel on both sides?

stunnel basic usage is to add SSL functionnality as wrapper to non-SSL 
daemons. So it gives you HTTPS for free ;-)

Just a question about session data .. is that all stored in a cookie 
so that a client can alter session data, or is just the session key 
available to the client?

only the key, session data is kept server side

right, the session cookies are just random keys, all session data 
is kept in Cheyenne's memory.

IIRC it is not recommended to store any actual data in cookie itself 
...

How would I send a binary file to a client?  Do I set up the correct 
http content headers, read/binary on the file, and then print it?

Isn't this just a mime-type issue?  Get the extension/file-type and 
let the browser
handle the download off a link?  Or am I missing something?

there's no link.

ahh...

when the client clicks on the download, I have to retrieve the file 
from outside the web space

im guessing...  

req/out/headers:  List of [name [word!] value [string!]] header pairs
req/out/content: to-binary read file

I'll give it a go.

Terry, I guess that Graham's question is related to RSP context, 
not Cheyenne module programming. (btw, the correct way to set HTTP 
headers in module is to use the 'h-store function (see in %mod-static 
for examples).

Graham: look in %docs/rsp-api.html, see in Response Object / buffer, 
you'll have an example of the correct way to send an image file to 
the browser (just set the correct mime type for your own file).

Thanks

I got it working for pdf and jpg, but when I use response/set-header 
'Content-type "image/tiff"  .. it downloads something, but locks 
up FF completely!

try it in REBOL console, download and save the tiff file and try 
to open it to verify that your image is ok.

if you wish to try it ...in FF only as IE can't see the animated 
menus


https://www.compkarori.co.nzas guest 1234 .. click on results->imaging 
, click on the Letter link, and then the link to the tif image ( 
A new one I just uploaded ).

This kills FF 2.04

I don't have any problem with FF.

I can see the image in FF, it's a 'Dell ad'.

I'm on FF v 2.0.0.4

Hmm.  Kills my PC.  Perhaps I have a problem with my PC then?

Time to reformat I guess...

just to add on,

it uses the Quicktime plugin to load the image in FF

It doesn't seem that FF can handle TIFF files natively, I don't have 
the QT plugin so FF just propose me to download the file. I can see 
the TIFF file using my favorite imaging app, so no problem with the 
TIFF image.

Graham, if you really want to serve tiff images and maybe at high 
resolution, look here:
http://iipimage.sourceforge.net/demo.shtml

otherwise as Dock said, quicktime handle tiff format but..

tiff is evil.

tiff is a component based architecture, of which there is no standard 
on the minimal required components.  so can't even be sure of the 
direction of the image, if the image creator didn't include that 
info in the image,

plus, loaders don't understand all the tags, which further increases 
the nightmare.

tiff is only really cool, when you are sure, all your softwares can 
load and save tiffs amongst themselves and they all agree on what 
an image IS...

I've have 24 bit pictures saved from a $10k effects software load 
upside down, black & white in "the gimp".