World: r3wp

why not a mod_log  ;-)

might still be needed for MacOS X servers?

by app-root i mean that directory level which cheyenne will never 
try to reach above

ok

any relative path in a config file is normally calculated from there

again, why not allow these configs in the httpd.cfg file?

because, the httpd.cfg place is unknown to Cheyenne in this case 
;)

ah so you're talking about the embeded mode?

or then... what is "this case"  I'm obviously missing something here 
 :-)

nope, see the piratepad link from onetom, we were talking about relocating 
the whole Cheyenne working folder.

Dinner time here...

ahh.  k.

were we talking about such things? really? :D

this mod-userdir name is a bit misleading, i think. i was expecting 
some handler for the /~user/  pathes and the ability to automatically 
fire up workers with the right ownership based on the owner of the 
directory it's serving from

however, since the source version runs again with /core, i can hack 
whatever i want now

i just need the logs go out of the way in a binary version

in the binary versions

Doc, is it safe to do this:

req/in: make req/in [
	data: value
]

within any/all of the module phases?

safe in the sense that some code in uniserve/cheyenne might have 
an absolute reference to the req/in... and this could break the chain 
of command..

I think that it is safe, but you should test if Cheyenne still works 
correctly after such change anyway (too bad we don't have unit tests 
for checking in such case...;-)).

hm... i miss the "restful" routing layer :)

i would like to have rebol files with an object in them -- like asd.r 
qwe.r -- returned as json via the path /asd and /qwe

i was thinking making a webapp which returns on-page-end the to-json 
context load rejoin [%. request/parsed/file %.r]

but i get a 404 in an earlier step, i guess

i have a couple of ideas how to hack this, but what would be the 
"correct" way?

capturing 404 doesn't work because it won't know the url of the original 
request

hmm.. now how can i write a module for the binary version of cheyenne? 
can i?

I think the original URL should be in the INTERNAL_REFERER header. 
At least that's how I'm using it in my situation

That's with the (REBOL) CGI interface. I don't know if there's an 
easier way in RSP

I made a start on a mod-rest but can't access it at present .. looks 
like the server has changed ip address behind nat

how can i disable the caching of .rsp files?

You can't. Why would you need that?

because im modifying the rsp source and i don't want to reload the 
server every time

sometimes it seems it can detect the file change, sometimes it doesn't.. 
is cheyenne checking the modification date of the source file

?

ok, now, i have a more interesting problem

the POSTed and the QUERY-STRING seems to be concatenated in the request/content

i value the intent of handling the variables in these 2 places in 
a uniform way, but concatenating them at the raw level doesn't make 
much sense

this is my rsp: <% print to-string request/content %>

and this is the http request:  curl  -d '{"a": 1, "b": 2}' http://localhost:8080/?test

i wouldn't be happy to start a separate webserver just for a dumb 
rebol-json gateway

Cheyenne is checking the modification date and reloads the source 
if the timestamp changed.

json.rsp: <% print to-string request/content %>


>> probe read/custom http://localhost/json.rsp[POST {{"a": 1, "b": 
2}}]
connecting to: localhost
{{"a": 1, "b": 2}}

concatenating them at the raw level doesn't make much sense
 ?? Cheyenne doesn't do.

<Cheyenne doesn't do that.>

I think onetom uses POST and GET at the same time.

>> probe read/custom http://localhost/json.rsp?test[POST {{"a": 
1, "b": 2}}]
connecting to: localhost
{{"a": 1, "b": 2}test}

Ok, I see the issue now.

wow, thx

Also, the "concatenation" is done by your TO-STRING in your RSP, 
you should use MOLD instead to print REBOL blocks.

in the trace logs i saw #{7B2261223A20312C202262223A20327D} as the 
value of the content field