r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!Cheyenne] Discussions about the Cheyenne Web Server

Pekr
5-Jul-2007
[1908x2]
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 ....
Dockimbel
5-Jul-2007
[1910]
php.ini is optional
Pekr
5-Jul-2007
[1911]
the strange thing is, that it is waiting for timeout for so long, 
but it does not display 404 page ...
Dockimbel
5-Jul-2007
[1912]
Are you on Vista ?
Pekr
5-Jul-2007
[1913]
yes
Dockimbel
5-Jul-2007
[1914]
Are you allowed to connect locally on port 9999 ?
Pekr
5-Jul-2007
[1915]
hopefully so. First time I run php-cgi firewall asked me if I want 
to allow the port
Dockimbel
5-Jul-2007
[1916]
try with a telnet localhost 9999 after launching php to see if you 
can connect.
Pekr
5-Jul-2007
[1917x3]
I just tried in rebol console.
hmm, but on putty I get - sw caused connection abort
ok, got to go ...
Dockimbel
5-Jul-2007
[1920]
I'll try to setup a working package with Cheyenne and PHP that works 
here (WinXp) and will send it to you.
Pekr
5-Jul-2007
[1921x2]
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
] !
Dockimbel
5-Jul-2007
[1923x2]
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.
Pekr
5-Jul-2007
[1925x3]
>> 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
Graham
5-Jul-2007
[1928]
Pekr, download vmware, or virtualbox and install XP.
Dockimbel
6-Jul-2007
[1929x2]
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
Pekr
6-Jul-2007
[1931x5]
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 ...
Dockimbel
9-Jul-2007
[1936x2]
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
btiffin
9-Jul-2007
[1938]
Go Doc Go!
Maarten
9-Jul-2007
[1939]
Go go go!
Dockimbel
9-Jul-2007
[1940]
:-)
Terry
10-Jul-2007
[1941]
Doc, Doc .. he's our man,
If he can't do it, no one can,
goooooo Doc!
Terry
11-Jul-2007
[1942]
If Carl was around more, maybe he'd get more cheers too?
Graham
11-Jul-2007
[1943]
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 ?
Dockimbel
11-Jul-2007
[1944x2]
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
Chris
11-Jul-2007
[1946]
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.
Dockimbel
11-Jul-2007
[1947]
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.
Oldes
11-Jul-2007
[1948x3]
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
Chris
11-Jul-2007
[1951x5]
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...
Graham
11-Jul-2007
[1956x2]
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