World: r3wp

Does the rsp evaluate files included using include-file ?

no

I've converted my site to https as well using the above howto .. 
only took 2 mins.  As you say, I have to generate a new certificate.

https://www.compkarori.co.nz/

Where is the debugging javascript added ?

when debug is true?

I just recently received whole new website for our Xidys site ... 
it is - templates, but there is some php code in there, and it sucks 
- they did not tell me ;-) Unfortunatelly, templates are easy. They 
did a trick, when whole top, bottom section plus left menu is one 
template, and content is "included" into the template, according 
to what item you choose in the menu. The advantage is - you don't 
have repeating part on more than one place. Disadvantage is - when 
you want to display the content part, you easily can't, as that template 
waits for inclusion, does not have headers, and hence it does not 
link to css - that aproach sucks, it does not work without whole 
production environment ....

Terry, what method are you using to intercept 404s?

Chris, I basically set Cheyennes current mod-static to return false 
if 404, then created a module with the same phase with a 'if 404...' 
function. This second url-to-filename is set to 'last' in the new 
module.

Another approach could be to install in your module a callback for 
'filter-output phase (not used in any builtin modules, yet) and test 
the return code. This way, you wouldn't need to patch mod-static 
and if you give it  order: 'first, it should be able to work even 
when I'll add callbacks to that phase. The purpose of this phase 
is to allow last minute changes on the response content, like encoding 
(think about JSON, for example), compressing (gzip, deflate) or encrypting 
it. These kinds of handlers would be installed as 'last in the phase 
callbacks order.

Here's an untested example  :

filter-output: func [svc req conf][
    either req/out/code = 404 [
        ...do_your_processing...
        ...
        true
    ][
        none
    ]
]

While I'm at it...here's the complete module code :

install-HTTPd-extension [
    name: 'mod-404
	
    order: [
        filter-output	first
    ]
	
    filter-output: func [svc req conf][
        either req/out/code = 404 [
            ...do_your_processing...
            ...
            true
        ][
            none
        ]
    ]
]

(don't forget to add the module name in httpd.cfg to make it loaded 
by Cheyenne)

I've fixed all issues related to session cookies and timezone (Windows 
platform included). Cookies strings are now only built once then 
cached, resulting in a litttle bit faster RSP processing. It will 
be included in the next version with other fixes and improvements 
in a couple of days.

Thanks Doc...Your efforts are not going unnoticed...under appreciated 
maybe  :)

Cheyenne is a key technology for my company, so we need to improve 
it rapidly, to be able to build higher levels frameworks, tools and 
applications (most of them will be open sourced). I currently have 
the opportunity to work most of my time on that project, that's why 
you see new releases coming often. I hope to be able to continue 
at the same rate for a couple more weeks, goal is to reach a v1 release 
candidate asap (some non-essential planned features might be kick 
out for v1.x in the process).

I'm grateful to you all, guys, who give me useful feedbacks and have 
the patience to wait for bug fixes ;-)

I hope later on you will be able to migrate it to R3 :-)

I've haven't grokked modules yet ... using the above, how do I generate 
a standard 404 page?

response/set-status 404 (see Response object API in %docs/ folder)

Pekr: sure, Cheyenne/Uniserve will benefit a lot from R3!

Graham: maybe I've missed the meaning of your question, you were 
talking from the module perspective ? From within a module's callback, 
to generate a 404, just use : req/out/code: 404 return true

What are your thoughts regarding SSL discussion earlier?

Here's Doc's 404 mod with processing for custom 404 page

install-HTTPd-extension [
    name: 'mod-404
	
    order: [
        filter-output	first
    ]
	
    filter-output: func [svc req conf][
        either req/out/code = 404 [
            
			req/out/code: 404
			req/out/content: "YOUR 404 HTML HERE"
			true
        ][
            none
        ]
    ]
]

note everytime you change this module you need to restart .. should 
probably change req/out/content to... 
req/out/content: read %mycustom404.html

Can then change the 404 page without restarting server

How you detect that the page request is http and not https so that 
you can redirect the request?

It's in the req object i guess?  try req/in/path

and parse

Ok.

Im finding the 404 mods second either block [none] is not working.. 
getting a 204 'no content' error

or it's not loading the existing file?

actually.. it's fine.

Using this stunnel means that remoteip is all 127.0.0.1 :(

-T
    Transparent proxy mode.


    If your machine supports it, stunnel will operate in transparent 
    proxy mode. Thus it will connect to the destination machine as if 
    it were the remote/client. In other words, the service to which you're 
    connecting will see the actual source IP address, rather than the 
    machine upon which this stunnel daemon is running. Helpful to maintain 
    good logs.

-p file

tansparent mode works on linux... not stated if it works for win32

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?