World: r3wp

ok, enough ... I will order my guys to prepare new notebook with 
XP Pro for me ...

A little update about the work in progress on Cheyenne's new version 
: I'm a little late on schedule (one week), I should release the 
new version tomorrow with several big improvements. The PHP/FastCGI 
final support involves some redesigns of mod-fastcgi that take much 
more time than expected. The good news is that it will result in 
a simple, fast and reliable interfacing with PHP. The other new features 
includes : text localization framework for RSP, support for any CGI 
scripts (including non-REBOL) and a new file upload system using 
temp files on disk (up to 2Gb files supported!). Once PHP support 
will be finished, I'll declare the first 1.0 release candidate (with 
encapped versions released too). I'll write all the docs during this 
debugging phase, so the completed 1.0 should be ready by the end 
of this month. I'm full time of Cheyenne starting from today, so 
it's doable.

full time of => on

Go Doc Go!

Go go go!

:-)

Doc, Doc .. he's our man,
If he can't do it, no one can,
goooooo Doc!

If Carl was around more, maybe he'd get more cheers too?

This is from the Rebol cookbook 

REBOL [Title: "HTTP Post Uploader"]

    url: http://www.rebol.net/cgi-bin/test/post.r
    data: read/binary %/c/rebol/rebol.exe

    print ["Sending Size:" length? data "Checksum:" checksum data]
    result: read/custom url reduce ['post data]
    print ["Server Replied:" result]

how does Cheyenne cope with this type of post ?

No tested, but I don't why this would be a problem for Cheyenne, 
as long as it's a valid HTTP request. There's only two upload encodings 
that Cheyenne currently doesn't support: multipart/mixed and chunked. 
Chunked encoding is only supported in Cheyenne's responses.

I don't => I don't see

Graham, the only problem with that Rebol lies in such cases -- it 
automatically sends 'Content-Type: application/x-www-form-urlencoded', 
even if you try to override it.

Good point, Cheyenne may fail decoding the Posted data if it's not 
in url-encoded format. The only workaround is to set Content-type 
to something like  'application/octet-stream.

chris: using my cookies-daemon you can send multipart data if you 
need it (as it's part of my http patch)

so the code above can be rewriten as:

do http://box.lebeda.ws/~hmm/rebol/cookies-daemon_latest.r
url: http://www.rebol.net/cgi-bin/test/post.r

result: read/custom url [multipart [myfile %/c/rebol/rebol.exe]] 
  ;== same like <INPUT TYPE=FILE NAME=myfile>

but as I'm now looking at the example above, it's not good way how 
people should post binary data at all

I have an embryonic Rest protocol (doesn't work properly yet).  It's 
a reimplementation of http designed more for web services (Rest, 
not soap, though soap if you wish).

; requires QM
do http://www.ross-gill.com/QM/qm.r
context load http://www.ross-gill.com/r/rest.r

Still doesn't read the sub-port correctly, but the idea is to build 
requests:
res: read/custom http://example.com/upload.r[
    action: 'post content: "REBOL [] message" type: 'text/x-rebol
]

Sorry, rest://example.com/upload.r

Anyway, better discussed in the Ports group...

Yes, I'm surprised that Carl's example works.  It sends data as binary 
but claims it is url-encoded.

In fact I suspect that it fails because the data is not url encoded

Cheyenne new version 0.9.16 is ready. The new FastCGI multiplexed 
support took me some time to debug, but the resulting PHP interfacing 
is now really stable. I just need to update the RSP API doc and run 
a few tests, so the download link will be published here in a couple 
of hours.

heh, will try once again on my Vista :-)

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

Changelog :

v0.9.16 - 12/07/2007
	
	o Localization framework added to RSP. API overview :
	
		- #[text] in static parts of RSP pages will be translated.
		

  - new function: say "data" : translate a string! value in the current
		  language.
		  
		- session's new 'lang variable can set the current language.
		
		- new config file options to control default language and 
		  locales resources folder.
		

 o Decode-cgi rewrote from scratch. Cleaner and 2-3 times faster than 
 before.
	

 o RSP request params decoding rewrote. Now GET and POST parameters 
 are unified
	  in request/content.
	  
	o BugFix for encapping %misc/mime-types file.
	

 o File upload support redesigned. Now big files (user defined threshold) 
 are

   directly written to disk in temporary files, instead of being held 
   in memory.

   The temporary files are deleted once the request is completed. So 
   now

   Cheyenne supports files upload up to 2Gb (R2 port! limitation).
	  

 o CGI execution extended to any scripts (not just REBOL). If found, 
 the

   shebang line (#!) is honored (on all platforms). Several perl scripts
	  added in %www/ folder as demo.
	  

 o Module's 'on-started event now fired only once, when multiple HTTPd 
 instances
	  are listening on more than one port.
	  

 o New module : mod-extapp for launching and managing external applications.

   Only the start and shutdown actions are currently supported. Load 
   balancing
	  will be included in future.
	
	o FastCGI protocol reliability improved and some bugs fixed.
	
	o RSP-API documentation updated.

To enable the PHP support: edit the %httpd.cfg config file, uncomment 
the indicated section and change the path to the php-cgi binary, 
that's all. The new mod-extapp will launch and kill PHP for you.

For RSP users, watch out the new way GET and POST parameters are 
unified, it may break some of your scripts (the ones using POSTed 
form data).

perl demo CGI are in %www/perl/

On windows platforms, you'll get the infamous DOS window flashing 
when executing an external CGI ! It's just a matter of 1 flag to 
correctly set in 'call C source code, if you're really annoyed by 
that, ask RT to fix it asap (for 2.7.6 that would be good)! ;-) I 
may reimplement completely call command in REBOL, but it would be 
a big waste of time and energy...it should be a 10 minutes fix for 
RT. Addind a time limit to 'call would be a good thing too, it would 
also avoid me the reimplementation of 'call to add such feature....

so cool ...

In theory, Cheyenne should be able to connect and pass requests to 
any FastCGI application, but it was only tested with PHP.

any chance of getting:

AddHandler rebol-cgi-dispatch .html
Action rebol-cgi-dispatch /cgi-bin/rebol-cgi-dispatch.cgi

to work already? :-)

No yet, I want a better API and config options than Apache which 
is a real mess ! So, I have a prototype of how it should be a AddHandler 
option should be added, I need to mature that a little more before 
implementing in the next release. Maybe I'll write an article on 
Cheyenne's blog about that to have some feedback....

would be good ...

Maybe something like:

process .html by "/cgi-bin/rebol-cgi-dispatch.cgi"

spec in pseudo code: 


process [any [extension | URL | folder | filename]] by [handler | 
URL-with-target]

BTW, I didn't have time to test this new release on linux, especially 
the external application launcher...Will test that tomorrow.

Doc - does app need to be encapped to hide in Systray?

Doc - above could be sufficient ....

To hide REBOL consoles, just start REBOL with -w option.

or encap Cheyenne ;-)

Doc - maybe we can fix that black dos window? I do remember some 
fix which hacked rebol exe, but dunno what it was related to ....

Doc - from config - is php supposed to be in ..\php dir?

Can I have more extern apps? E.g. more php versions?

Firefox offers me download of test.php, instead of executing it? 
Maybe a mime-type incorrectly set?

it should not offer me to download the script, or it is security 
issue imo :-)

Check if your php-cgi.exe process exists

PHP can be anywhere you want, just set the correct (relative or absolute) 
path in the 'command directive

You can have more than one php-cgi process, but the pooling support 
is not yet implemented. For PHP, to control the number of threads 
(Windows) or processes (UNIX), just set the PHP_FCGI_CHILDREN parameter 
to the number you want. If you don't know what this is about, just 
leave the default value (1). Even with that value, it can supports 
dozens of concurrent requests (thanks to the fastcgi multiplexing 
support).