World: r3wp

MikeL: good idea, btw, I plan to add a "Reload Config File" option 
soon in this menu.

Re: config control panel: there's some experimental stuff, but it 
still needs a better internal design. If you need to expose some 
parameters, just fill the words: [...] block in your module definition 
and add some config options.  (this is  not yet documented, but by 
looking in mod-static or mod-action, you'll figure out easily how 
to use that feature).

I changed port-id in httpd.r to 8100, but it still serves on port 
80

I once had the same problem

there were twho httpd.r scripts in the distro.

Doc was fixing that IIRC. One of them was experimental and was supposed 
to be removed.

so - not sure it is your case ...

it's not enough to change it in the httpd.r... start your server 
from shortcut using for example D:\view\rebol2705031.exe -sq cheyenne.r 
-p 800

how is that? why is that not enough?

what is that option in httpd.r there for then? :-)

you can listen no only one port

cheyenne.r -p 800,8100

Thanks, that works.

Cheyenne.r does bypass settings in uniserve.r, httpd.r, etc, which 
is a feature! for example if you set verbosity in httpd.r, it will 
be bypassed by code in cheyenne.r which takes in command line parameters, 
look in the source of cheyenne, on the bottom ;-)

This allows me to pick up my previous cgi-bin scripts from Cheyenne

webapp [
		virtual-root "/cgi-bin"
		root-dir %/c/xitami/cgi-bin/
		debug    
  ]

You should not change the port-id in httpd.r, either change it in 
cheyenne.r, or better, use the -p command line option.

Pekr: it was http.r and http2.r protocols in UniServe.

Any chance of having the custom 404 a rsp page?

Graham.  404 response is defined in  httpd.cfg  and can be set to 
be .rsp e.g. 	
	on-status-code [
		404	  "/custom404.rsp"
	]

But it would be handy if  validate allowed for default values for 
parameters which may or not have been provides similar to what is 
done with the cgi object.

'validate sets parameters to none! if they are not provided. What 
does the cgi object for default values ?

I should extend 'validate spec block to allow custom default values.

Hi Doc,

I was referring to something like this 
   construct/with
                cgi-block
                   make object! [a: 111 b: 222 c: 3]


from http://www.rebol.org/cgi-bin/cgiwrap/rebol/art-display-article.r?article=x60w#toc-20



It could be added by all users to the results of validate but then 
it would be not be a standard cheyenne solution. It makes sense to 
me it is ''validate.

Thanks for the example. I agree, it's a useful feature. I'll see 
how I can improve 'validate to support that while keeping it  short 
and fast.

I think doc said before that it won't be processed as rsp if using 
a custom 404 handler like this.

any chance of getting something like AddHandler? :-)

404 can be an rsp

A little competition  http://www.server2go-web.de/

'on-status-code option allows you to forward to any local URL (incuding 
RSP, CGI or PHP).

I got it working .. maybe I was thinking of the earlier mod method 
of handling 404s

Pekr: AddHandler can be implemented now in Cheyenne. Should it work 
like in Apache (binding a handler to a file type) or can we make 
something smarter. Any ideas about that ?

Is there an example of handling multipart forms ?  ( http uploads 
? )

I don't have any ready, but you can easily try by using the show.rsp 
script as the target of a form uploading files.

Doing a simple test doesn't seem to work, there's maybe a regression 
on file uploads handling, give me a few minutes to test that.

Ok, that's what I though, the 'decode-multipart function hasn't been 
updated for the new RSP engine. Here's the new correct beginning 
for this function (located in %handlers/RSP.r) :

parse/all request/headers/Content-type [
			thru "boundary=" opt dquote copy bound [to dquote | to end]
		]
		if not bound [return ""]	 ;-- add proper error handler
		insert bound "--"	
		list: make block! 2
		parse/all data [
...

To test file uploading, here's a short HTML form (put it in %www/) 
:

<form action="show.rsp" method="POST" enctype="multipart/form-data">
	<input type="file" name="ufile" size="16" />
	<input type="submit" name="usubmit" value="upload" />
</form>

BTW, file uploads are currently stored in memory only. I'll improve 
that to use the disk instead for big files.

great

http://bytered.com/siteinfo.html- website running on a converted 
LinkSys NSLU storage device.

Just imagine converting these to run Cheyenne .. mini Rebol appliances

Thanks for the link, I plan to play with some small linux and R3 
to see how small it can be.

Doc, as for AddHandler. With Apache, I put following into .htaccess:

AddHandler rsp .html
Action rsp /cgi-bin/rsp.cgi


So above means - take .html and send it as a parameter to rsp.cgi 
... simply it is a reverse aproach from your RSP.

Petr, Isn't this AddHandler the same as was demonstrated with the 
Demo.r which can be defined in the %httpd.cfg globals section
 bind-extern demo to [.dem]


Add demo.r which in %handlers/  can do anything you like with the 
content?

MikeL - I am not sure I understand what you mean ...

so you think I could do:

bind-extern pekr-rsp to [.html .htm]

and then putting  pekr-rsp.r into %handlers/ ?

No, handlers need to implement "handler's API".

it's not that hard, thought, but currently undocumented.