World: r3wp

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

ah, that's the parsed/content

File = ./to-json.r
        ** Script Error : body-of has no value

i can use third instead of course but why is it not defined?

What REBOL version are you using?

onetom ~/p/ob/jsondb $ cheyenne --version
0.9.20.125

so i guess im not using an external rebol exe, since i have  bind 
RSP to [ .r ] in my httpd.cfg

Right, Cheyenne is processing .r with such config.

Can you <% print system/version %> ?

onetom ~/p/ob/jsondb $ curl http://localhost:8080/ver.r
2.7.8.2.5

also my rebol exe works like this:

>> system/version
== 2.7.8.2.5
>> body-of context [a: 1 b: 2]
== [a: 1 b: 2]

i guess u left of the r3 compatibility mezzanines from the encapping

if there is such a thing :)

I guess my Cheyenne build scripts are missing a R2/Forward specific 
include.

Found the issue, my Linux and OSX build scripts were corrupted with 
an older version pointing to 2.7.6 include files. I will need to 
rebuild them.

json.rsp:
<%= probe request/content %>
<%= probe as-string request/parsed/arg %>
<%= probe as-string request/parsed/content%>
<%= probe request/parsed/arg %>


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


Some corruption is occurring, request/parsed/* should be left untouched.

thx, doc for the quick responses! i feel a bit quilty though, coz 
u can't work on red instead, but hey, let's make what we already 
have bugfree 1st. these needs to be fixed even if we run it over 
red, right? :)

Right, important bugs have to be fixed asap.

Ok, false alarm, no bug in RSP request decoder:

json.r
<%= mold request/content %>
<%= mold as-string request/posted %>
<%= mold as-string request/parsed/content %>
<%= mold request/parsed/arg %>


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

The <%= in addition to PROBE was producing a misleading output.

onetom: your concatenation issue was caused by the usage of TO-STRING 
instead of MOLD.