AltME groups: search

first / normal / last : that's the position in phase list, you'd 
like for your function in a given phase

the position determines the calling order in a given phase

I take it the module order in the config file is a type of position 
as well?   if the tirst module returns true, then the rest not considered?

I can see how that could be a bit tricky.. somewhat bug prone

(sounds like a module :)

This system is very flexible, but if not carefully done, can lead 
to a messy organization. I plan to move to a more simplified system 
(but more restricted too) for Cheyenne 2.0 (not before 2008, I guess).

One last question for now if you don't mind.. sending a response 
back to the page.. .. is this correct?
req/out/content: "test"

Do you have a really basic make-response function?

That's great..   so very extensible.. I have a really basic core 
Chyenne, and can add mods as I go..

I've done some stress test on a previous version of Cheyenne, it 
was sustaining around 500 concurrent connections on static pages 
requests. (RSP have a limitation of  <500 due to a design bug in 
task-master. This bug will be fixed in a few days).

sessions: Is it possible to add a cookie-free session handling by 
adding a session ID to the URLs?

Session currently only use cookies. The session ID is available (session/id) 
so you could embed it in urls, but session cookies support is hardwired 
in the RSP engine, so it would require a lot of internal changes 
to not rely on cookies.

<%= - nice ... that'll save a bit of typing :)

Note: so long as QM is server neutral (i.e. it's Apache friendly), 
it will not be as efficient as it could be under Cheyenne.  I really 
would like to do a Cheyenne-only version, but not until QM is feature 
complete (and I will say 'stop' as some point :)

Unfortunately it's a requirement :(

Doc, exactly. A lot of companies don't allow cookies for their employees...

althought the meaning of this is still a mistery for me ;-)

anyone in a hurry to have global and per domain rewrite-rules?

Is there a verbose logging feature for cheyenne?

HTTDd.r has a verbose mode.

may be a browser limitation, experienced same issue here depending 
on browsers, also some do not eat cookies when using ip instead of 
hostname in urls

Is there a possibility of using the standard sql dialect for 'do-sql 
?


eg [ {insert into table (one, two, three ) values (?,?,?)} a b c 
]

it should work if your DB driver supports it, DO-SQL is just a higher 
level wrapper.

Graham: it seems that I've found a bug the session expiration in 
Cheyenne, that might be the cause of your error. It's now fixed. 
I'm testing it a little more before releasing it, I'd like to fix 
the cookies issues of Brian and Terry too (one way or another, these 
issues must be related to the info Cheyenne is sending back in the 
response).

Seems that I found the guilty for the weird session cookie issues, 
need to dig up a little more to confirm the theory.

so, is cheyenne querying the database after the query expecting a 
response ?

do-sql is doing an INSERT on the database port, then a COPY on the 
port. Does your query only require an INSERT on the port and no COPY 
?

if the client is behind a router and has a local IP NAT-ed by the 
router, no way.

I never do a copy on a db-port after an insert

There's a workaround until I publish the next release (later tonight), 
use : insert databases/remr query

can we log this to a local log file ?

it is tested in cheyenne.r startup code and if defined, it will try 
to catch all errors in a local %crash.log file

Not at all Graham, I should thank you for making a big leap forward 
to Cheyenne's stability and reliability. :-)

The session cookie problem is related to incorrect timezone calculation 
in cookies expire time. I'm making a fix for Cheyenne, but due to 
a REBOL bug on Windows (http://www.rebol.net/cgi-bin/upnews.r?view=0005), 
I can't find an easy solution for that platform...

So I guess that I'll add a config option for setting the correct 
timezone for Windows users manually and for /Pro users, I'll support 
the GetTimeZoneInformation() win32 function for automatic setting.

Cheyenne release v0.9.12 beta. Download at http://softinnov.org/tmp/cheyenne-r0912.zip

Changelog :


 o do-sql function improved to support RT's DB drivers. /flat refinement 
 is 
	  supported now too. ODBC insert error fixed too.
	
	o RConsole prompt changed to "Server>"
	
	o CGI's 'path-info now returns the request URL.
	

 o Fixed a bug in RSP session destruction potentially corrupting the 
 internal 
	  session list and giving weird results or behaviour.
	  

 o Fixed a timezone computation bug that was setting incorrect expire 
 times for 

   session cookies, resulting in unstable behaviour. All platforms except 
   Windows.
	  

 o Small patch to parse-request-line func in HTTPd.r to be more 'mod-rewrite 
	  friendly.

I'm still not having any luck runing php scripts.  test.php does 
not produce a result...jst a blank page.

Nenad, proably not necessary to have a method to restart modules 
after modifying... simplly dumped the code into an external file, 
and 'do that instead.

um.. i 'do a script to handle my url-to-filename phase

Im intercepting 404s.. and processing them through a main script 
that handles the DB, generates responses etc.

only a true geek has fun with this stuff.

( I guess that makes me a geek ;)

RE: "How does Cheyenne's performance and security stack up against 
the other indians (Apache, Cherrokee, Hiawatha, ...)?"


Speed: close to Apache2.x for static files (tested a year ago, so 
new tests need to be conducted).


Security: not chroot-ed and no special protection against ddos attacks 
like Hiawatha, no bandwidth throttling (could be added), no CGI time 
limit (could be added), passes Nikto generic security tests flawlessly 
(last time check : few months ago)

I think a biggy will be SSL support

I suppose one issue will be connecting to the library.. would require 
view/pro?  Can call the binary, but it's a less elegant solution

This method is for windows.. and runs a shell

If you want to try this method for windows.. here's what you do.. 


1) download the windows binary from openssl.. ->   http://www.slproweb.com/products/Win32OpenSSL.html

2) Unzip.. and pull out the openssl.exe file from the bin folder.. 
. drop that file into your cheyenne www folder
3) Create a self-signed cert....
3a) run openssl.exe

3b) enter this line: req -x509 -nodes -days 365 -newkey rsa:1024 
-keyout localhost.pem -out localhost.pem
(localhost is the cert name)

3c) answer the questions... when asked 'who are you?' enter your 
domain,  or 'localhost' as I did 

This will generate the cert in your www folder (this is just a demo... 
the openssl server uses it's location as root www folder)

4) Start up the server... enter this line into openssl:  s_server 
-accept 443 -cert localhost.pem -WWW


Now open any file in your Cheyenne www folder using the https:// 
 protocol

don't need to put into root folder (probably not a good place for 
the cert by the way)

You'll want to use OpenSSL to generate a cert for Stunnel to replace 
the default

If I have a large amount of html that I want to reuse in each page, 
rather than including it from the disk, can I define them as rebol 
variables to be reduced inside rsp pages?

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/

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 ....

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.

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.

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've haven't grokked modules yet ... using the above, how do I generate 
a standard 404 page?

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

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

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).

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 :

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 :

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.

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?

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?

I'll give it a go.

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 ).

I don't have any problem with FF.

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

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

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,

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

but since tiff allows people to create their own components within, 
 a few "standards" for high-end photography exist IIRC.  These usually 
include HDRI imagery and things like lens aperture and other goodies... 
now, before you get all fuzzy and warm inside.... it doesn't mean 
the data is readable by open softwares, just that its there...

I have a past project which *might* need to be replaced by cheyenne... 
but I will have tons of questions for sure... and without quick response... 
I am a bit wont to put time on this fix... since I am not totally 
sure it will do what I need....

Max: I'll be online in AltME from 9 jun to 13 jun most of the time, 
so, in this range, I should be able to answer your questions in  
12 hours max delay. But I guess other people, like Will, could also 
answer most of your questions. If you have a lot of questions,m aybe 
it would be better to send them on a private channel, or Chat channel.

thanks.  is the MOD system flexible enough to allow the server to 
be something else than a "WEB" server...  more precisely, a web service, 
I already have all the XML and schema validation libs to make it... 
its just that my current server is blocking and when I relay commands 
to othe servers, it causes timeouts on new commands.

has anyone succcessfully used OpenSSL, or is it still a "just use 
OpenSSL" suggestion...

Graham: there's some experimental stuff about that in mod-internal, 
but still needs some improvement to be ready to encap a complete 
web site in the Cheyenne binary. But that's a planned feature, I'll 
provide better support for that in a week or 2.

Maxim, I'll provide this weekend a new module for easy Cheyenne embedding 
in third-party REBOL application. It should give you all the hooks 
you need to interface with your code and build your specialized server.

May I help?  <- note there's a capital M and no space before the 
question mark.

I'm thinking this is not a good error to get ..

Script: "Untitled" (none)
## Error in [task-handler] : Make object! [
    code: 316
    type: 'script
    id: 'no-memory
    arg1: none
    arg2: none
    arg3: none
    near: [insert tail series :value]
    where: 'append
] !
/

I think it happened when I left the trailing %> off a rsp page.

How about including a global url-encode function ?

I've got a new problem

Cheyenne release v0.9.14 beta. Download at http://softinnov.org/tmp/cheyenne-r0914.zip

Changelog :

o response/forward improved : 

 - fully supports URLs as argument (can now forward to another virtual 
 host).
	- URL validity check (must have an explicit target).
	- protection against cycles.


o Command line option -p extended, now you can specify several listen 
ports separated
   by a comma (ex: -p 80,10443).


o New command line option -e : load and initialize Cheyenne without 
entering the

   event loop (needed for embedding Cheyenne in third party apps).


o Added a new experimental module: mod-embed. Purpose is to allow 
easy Cheyenne

   integration in third-party REBOL applications that require an embedded 
   web
   server. (Uncomment mod-embed in httpd.cfg file to activate it)


o Added %embed-demo.r file to show a sample of the mod-embed usage 
and API. 

o RSP: <% without %> eats all the memory. Fixed.

o URL-encoded request values were not parsed correctly. Fixed.


o RSP: fixed a typo in 'decode-params blocking the multipart data 
decoding and
   also a local word ('type) leaking in GC.

o UniServe's service startup refactored to be more flexible.



The new mod-embed is experimental. Please look at the %embed-demo.r 
file and send your feedbacks here.

This is somewhat historic imho.  Embedding a full featured web server...historic.

must be a mistake

(that's a compliment ;-)

Archive re-released with a fixed test for 'do-events.

If the session ID is persistent in a DB any Cheyenne can handle the 
request

Other question: how do I create a friendly URL mapping in Cheyenne? 
using the publish-site dialect?

(hope I'm not too demanding, just trying to match Cheyenne against 
a lot fatures I use in my projects)

If you're using Cheyenne in embed-mode, 'publish-site let you define 
whatever URL mapping you want. In standalone Cheyenne, there's no 
general way to define URL mapping, it's currently up to each module 
(CGI, RSP,...) to handle their specific mappings. I'm hoping that 
the future mod-rewrite will allow efficient and general URL mapping 
(there's a mod-rewrite published by Will, who could already do that).

I think that embedded mode might be the killer. Especially if you 
can combine it with encapsulation on a virtual file system

Is there a module writing 101?

About the DB stored sessions shared across multiple Cheyenne instances, 
it would require a significant change in the current way session 
data and especially, session synchronization is handled (currently, 
it relies on semaphores and queuing to achieve that).

OK. The other option is using a load balancer that support sticky 
sessions

ah ;)  yeah.. its a hassle