World: r3wp

  in parameters value =

=> known bug

will be fixed in next release (should be tonight)

Ok, thanks

double quotes, that's normal they are present in the URL : https://www.compkarori.co.nz/testapp/filteredhl7.rsp?rtype="O2Sat"

Is the bug database online Yet ?

Ok.  About the double quotes

unfortunately, not yet, I'll try to put it online after the next 
Cheyenne release (so, it could be online tomorrow).

Quick patch for url-encoded value bug: 

1: in %HTTPd.r find the 'parse-request-line function
2: change the following line :

    parse/all dehex ctx/status-line: copy line [
to
    parse/all ctx/status-line: copy line [

3: change the following line :

    ctx/url: path: trim url
to    
    ctx/url: path: dehex trim url

Marteen: about docs, the RSP API document will be published tonight 
with the new release. The module API is still incomplete and the 
general Cheyenne main doc is still pending (scheduled to be released 
for 13/06).

Sounds good!

I'm having trouble getting Cheyenne to display web page with an absolute 
path. It works when Root-dir is set to  %/www/ but when I set it 
to the absolute path ...say %"C:/Rebserver/Cheyenne/www/" I can not 
get hte default page but I do get my test.php script to work.

It works for me but you might want to try using the rebol format 
on the directory name %/c/rebserver/cheyenne/www/

That works. Thanks Mikel

url-encoded patch working :)

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.

the mad Doctor cranking it out ;)

so, i take it each  mod-embed can have it's own listen port?

hmm.. followed the instructions.. uncommented the httpd.conf (need 
to comment out the others??)

[uniserve] Async Protocol FastCGI loaded
[uniserve] Starting task-master...
[uniserve] Starting HTTPd...

## Error in [uniserve] : On-received call failed with error: make 
object! [
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'in
    arg2: 'object
    arg3: [object! port!]
    near: [if in site 'on-request [
            if site/on-request req params svc [return true]
        ]]
    where: 'handler
] !

ahh ok.. need to run embed-demo.r rather than cheyenne.r.. working 
fine now

very very cool.. perfect for this current project

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

Well, you could do this with Uniserve long ago.. just not with such 
ease and organization.

trailing slashes seem to play an important part.. will this be an 
issue with improperly formed urls?

cookies still not working with xp ?

Ok.. sessions work if i use 127.0.0.1 rather than localhost

Script: "Cheyenne Web Server" (9-Jun-2007)
Script: "Untitled" (none)
[uniserve] Async Protocol FastCGI loaded
[uniserve] Starting task-master...
[uniserve] Starting HTTPd...
make object! [
    code: 300
    type: 'script
    id: 'no-value
    arg1: 'do-events
    arg2: none
    arg3: none
    near: [do-events]
    where: none
]
>>

Needs rebol/view ???

>> do-events: func [
[        "Process all View events."
[    ][
[        wait []
[    ]
>> do %cheyenne.r
Script: "Cheyenne Web Server" (9-Jun-2007)
Script: "Untitled" (none)
[uniserve] Async Protocol FastCGI loaded
[uniserve] Starting task-master...
[uniserve] Starting HTTPd...

in cheyenne.r:
- if unset? 'do-events [do-events: does [wait []]]
+ if not value? 'do-events [do-events: does [wait []]]

must be a mistake

instead of using do-events, just use wait []

do-events == wait [ ], the docstring inside do-events func spec is 
not accurate, it should be "Process all events".

Woha!

(that's a compliment ;-)

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

2 questions: will you combine this with nysql:// ? I would like the 
session management to be databse driven so that load-balancing becomes 
easier?

*mysql://

hum, it should be possible to store session data in DB, but you'll 
loose performances compared to keeping it in memory (it's stored 
in Cheyenne's main process).

what kind of load-balancing architecture do you have in mind ?

multiple web servers with sessions and database driven content. So 
based on the session ID i generate personalized content

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

Ideally, you can configure the session mgt backend in httpd.cfg

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