World: r3wp

you have my httpd.cfg above - does it seem to be configured properly? 
my php is coming from .zip, I copied it to c:\php, went to this directory, 
typed php-cgi -b 999 (enter)

then started cheyenne. It runs ok, as it serves my pages ... but 
no luck with test.php

Your config seems ok to me.

Try rebooting your browser if you're using IE.

Graham: yep 3 console if no in 'quiet mode (default is quiet, so 
only 1 console then). In encapped, it depends on the encap headers, 
you should have one by default (can be removed by using the 'no-window 
encap option in headers).

...3 consoles if not in...

shouldn't I set docroot also in php.ini?

You can try that (but it should not be required if you're running 
PHP from the ZIP package).

Does your browser timeout on test.php or does it return a 404 ?

there is no php.ini, just php.ini-dist, php.ini-recommended

no, it does not.  OK, I will delete my website and put back whole 
your testing environment ...

hmm, no luck here, I give up on php. Whole other Cheyenne content 
runs ....

php.ini is optional

the strange thing is, that it is waiting for timeout for so long, 
but it does not display 404 page ...

Are you on Vista ?

yes

Are you allowed to connect locally on port 9999 ?

hopefully so. First time I run php-cgi firewall asked me if I want 
to allow the port

try with a telnet localhost 9999 after launching php to see if you 
can connect.

I just tried in rebol console.

hmm, but on putty I get - sw caused connection abort

ok, got to go ...

I'll try to setup a working package with Cheyenne and PHP that works 
here (WinXp) and will send it to you.

ok, thank you very much! for local testing, I want to have my stuff 
on USB, not being dependant upon apache and php install :-) It would 
be nice, if it would work ...

tried your package:

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

## Error in [uniserve] : On-received call failed with error: make 
object! [
    code: 311
    type: 'script
    id: 'invalid-path
    arg1: 'handler
    arg2: none
    arg3: none
    near: [either in port/locals/handler name: 'new-insert-port]
    where: 'insert-port
] !

seems that on your machine, the fastcgi client cannot connect to 
localhost:9999...strange, can you test this in console mode : >> 
read dns://localhost

The package works ok on WinXP.

>> read dns://localhost
== 127.0.0.1

but I can't telnet to it by putty .... strange .... After 3 months, 
I am still not used to Vista - that system is total garbage ....

maybe there is some kind of dns error. I tried in IE right now, it 
seems to load some page, which is empty - nothing appears on screen. 
So I pressed right mouse button/properties, and there is following 
item: 

res://ieframe.dll/dnserror.htm#http://localhost/test.php

Pekr, download vmware, or virtualbox and install XP.

Pekr, you have an issue with your localhost DNS resolution. You should 
check that your hosts file is not messed up. If you can fix the localhost 
problem, here's a workaround, in Cheyenne archive, edit the mods/mod-fastcgi.r 
file, find the fastcgi://localhost:9999 expression and replace it 
by : fastcgi://127.0.0.1:9999, that should work.

can fix => can't fix

ok guys, will try that ....

I think that I will soon change my whole notebook - slower hd, more 
memory, more battery life, XP profi instead of Vista. I still can't 
get used to it ...

content of windows/system32/drivers/etc/hosts file:

127.0.0.1       localhost
::1             localhost

- ping localhost works in shell window
- print read dns://localhost works in rebol
- change in mod-fastcgi did not help ...

I still get the same error:


## Error in [uniserve] : On-received call failed with error: make 
object! [
    code: 311
    type: 'script
    id: 'invalid-path
    arg1: 'handler
    arg2: none
    arg3: none
    near: [either in port/locals/handler name: 'new-insert-port]
    where: 'insert-port
] !

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.