World: r3wp

i'd be interested in looking into the sessions during runtime too.. 
can i do it on the cheyenne console by pressing escape?
You can access them in 3 different ways:


1) if run from sources, escape in the console, then enter: probe 
uniserve/services/httpd/mod-list/mod-rsp/sessions/queue. Type do-event 
when you want to resume Cheyenne.


2) run the %clients/rconsole.r from the source archive, you will 
have a remote console connected to your local Cheyenne process (try 
on prompt: netstat)


3) add this to the config file in globals section: persist [sessions]. 
When you want to look to the sessions, just stop Cheyenne process, 
a .rsp-sessions file is created holding the session objects.

onetom: sorry, I am not fluent in curl, I need to look for man pages 
for every options...Can't you use REBOL http client for testing?

sure, i can use. i was asking for an example as i how do u do it 
usually

i saw u r using rebol mostly, so i was expecting some rebol example

Does curl handle cookies automatically?

thats whats -c is for

it maintains cookies in a jar

Have you looked into the request/response logs from Cheyenne?

thats what im not sure how to handle w a little code in rebol, that's 
why i was asking u; thought u need have some examples in ur toolbox

yes, it's not sending the cookie as i would expect on the 2nd run

$ cat jar
# Netscape HTTP Cookie File
# http://curl.haxx.se/rfc/cookie_spec.html
# This file was generated by libcurl! Edit at your own risk.


#HttpOnly_guan-huat     FALSE   /       FALSE   0       RSPSID  MTXVGMVOMYMVGDZKFURKPQKK

i will read up on curl, im just asking how would YOU do it from rebol

You should try to send a GET request first on the login.rsp page.

I'm using either REBOL HTTP client for testing or my own HTTP async 
client (using UniServe) that can handle cookies. But I never need 
to test my webapps programmatically (at least not so far).

okay, thx

When I need to debug an HTTP communication, I either look into Cheyenne 
reques/response logs or I use firebug.

Here how it goes with REBOL native HTTP client: http://piratepad.net/KkvkZ9AtME
 (see at bottom)

my bad. seems like i should use -b to read the cookies. -c just writes 
them...

You should stick with REBOL HTTP client, using this patch to add 
transparent cookie support: http://www.rebol.org/view-script.r?script=my-http.r

i think i was using that once. it's just not default in rebol... 
:/ curl however is present on every machine i have access to...

so it's worth learning.

i was a wget user earlier, but since macs come w curl and i can easily 
apt-get install curl and even syllable comes w curl, i don't give 
a fuck anymore how an inefficient bloatware is curl, im still trying 
to use it and only it :)

my-http is nice though. i wish there would be a guide for all these 
protocol extensions.. there are a couple of half-baked versions of 
them... :/

curl -D- -d 'login=test&pass=letmein' -c jar http://localhost:8080/login.rsp
curl -D- -b jar -c jar http://localhost:8080/some.html
worked, btw

Curl is not on Windows, REBOL is.

http://curl.haxx.se/download.html

Protocol extensions: right, they could have been listed somewhere 
on REBOL web sites.

it's actually available for a lot more platforms than rebol nowadays

Curl: I didn't know it was so widespread.

but of course the lack of proper console under windows makes the 
rebol solution more attractible.

btw, let me micro-interview you here: why the hell are u still using 
windows!? especially for development? :)

I think I posted some code using rebol client to login to session

u know if rebol would come w a nicer header dump, cookie, https and 
url encode/decode support by default, i would advocate it as a curl 
replacement probably... :/

maybe an extension script would be enough, which anyone can remember, 
like http://json.org/json.r

pff.. my-http is not really transparent...

>> do http://www.rebol.org/download-a-script.r?script-name=my-http.r

connecting to: www.rebol.orgScript: "patched HTTP/HTTPS protocol 
with cookies support" (18-Aug-2006)
== none
>> trace/net on
>> read http://localhost:8080/testapp/login.rsp

URL Parse: none none localhost none testapp/ login.rsp** Script Error: 
querying has no value
** Near: http-command: either querying ["HEAD"] ["GET"]

my-http might not have been upgraded for latest REBOL versions.

http://cheyenne-server.org/wiki/En/Sandbox
i distilled what we just talked about recently.

dunno which page should be the best for hosting such info, so im 
just braindumping here for later organization

btw, let me micro-interview you here: why the hell are u still using 
windows!? especially for development? :)


I consider that GUI are an improvement over CLI that make my life 
easier and computers simpler and more fun to use. I stick with Windows 
as my main platform because I never got used to Mac OS UI (tried 
for a few weeks, but gave up rapidly) and I found the other UNIX 
GUI less "efficient" than Windows. Also I found Windows to be quite 
transparent for my work, it just doesn't get in my way as other OSes 
tend to do, so I can focus on my work and forgot about the rest (especially 
since Vista days, I am now a very happy Seven user).


I must also add that I was an Amiga and BeOS user for more than a 
decade and spent all my college days on AIX, X-Windows and SunOS.

X-Windows => X-Window ;-)

:) thanks. interesting.

i was doing DOS, TurboVision, then tried Win3.0. used Turbo Pascal 
in 2 dos windows under Win3.1, programmed serial equipement with 
Delphi 1.0 under Win95, but then i just fell in love w the fvwm2 
theme of icewm and the big virtual desktop which even worked on trident 
8900 isa cards, using suse linux. i was forced using windows until 
the xp version and i even saw delphi 4.0.

no windows interface can compete with icewm with autofocus and saying 
this as someone who still can handle windows without a mouse faster 
than anyone else i know.

i found vista and win7 particularly disgusting. those dim windows 
w huge decorations just make me annoyed.
im the fullscreen terminal window in black&green kinda guy :)

i want console in web browsers too. i think lisp machines were great 
examples that how the character based interface can benefit from 
graphical capabilities.

plan9's acme is also a nice example; although i never had the chance 
to use it for anything real. never really seen an expert using it 
either...

btw, this is how im listening to netradio rightnow:
$ mplayer http://lounge-radio.com/listen128.m3u

and the good thing is, i could do the very same under windows, while 
i had my windows netbook

hmm.. cookies are accumlating again... Cookie: RSPSID=GWKAQXFYMANHFHNXLXXKVVWL; 
RSPSID=VDWMLITKUVGDAFQBHJHHCQDH

but the app still works. am i confusing it somehow, by restarting 
cheyenne... but im closing the tab and reopening it too...

this /favicon.ico pollutes the output... how could i get rid of it?

No, it a browser thing (unless you can disable it in your web browser).

IIRC, older session cookies stay if the session has not been explicitly 
ended (using response/end), or until browser window is closed

Cheyenne uses volatile cookies (with HttpOnly attribut) that are 
safe for holding a session key.

hmhm... the auth directive is not completely useful for me, because 
probably i shouldn't return a 302 to the login page when the session 
of my json service times out... :/

I'm stuck in my attempts to get Cheyenne to run as non-root. Some 
observations along the way

The encapped version of Cheyenne needs to be started from the directory 
of the configuration file in order to find it. Then it produces its 
log files also in that directory. This is both against the structure 
of Unix and modern Windows systems

To produce the logs, Cheyenne needs write access to the folder with 
the configuration file and (future) logs. This becomes a problem 
when it gives up its root capabilities, and the mechanism to adapt 
the privileges of the log files still doesn't seem to work

When Cheyenne has access to this directory, but only for reading, 
it quits silently. -vvvv doesn't even provide a clue what went wrong

When it gets write access, it produces a crash.log under the new 
user name, showing that it switched. But it had already produced 
a normal log under the root name, and doesn't adapt its ownership. 
This is indeed what the crash.log then warns about

Ah, the problem is the -vvvv itself. When I start Cheyenne with extra 
logging, it creates the log earlier, so that it ends up being owned 
by root