World: r3wp

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.

Looking into the missing mezzanines issue in Linux binary...

Re-released all v0.9.20 binaries to fix the missing 2.7.8 mezzanines.

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


You could try using the ALIAS config option. Add this to the httpd.cfg 
file in a domain section (not sure if it would work in a webapp context):

    alias "/rest" %rest.rsp

and call your REST resources with:
    /rest/asd 
    /rest/qwe


In %rest.rsp, you can put your URL parsing code to produce a "REST 
routing" and return the JSON object. It might also work with "/" 
(untested).

Doc, wrt req/in: make req/in   []    so far it works flawlessly. 
 I'm using this to store computed data from an early phase and sending 
it to the handler later.  This allows me to prevent double or tripple 
processing the same thing (a decision based on the url)

Extending the req/in object! is a good solution. I should maybe add 
a 'user field in request object for storing custom mod data...

(just to make it cleaner)

don't know, since then more than one mod might start to clobber it, 
and we'd be fighting for the space (same difference, just one level 
down  ;-)


and, since those extra bytes get molded/sent/loaded to and from handers... 
it seems like waste when for most people this data will not be used. 
   I'd actually rather document how a module should expand a request... 


like spelling any new word, starting with the mod's name to prevent 
collisions.

and documenting that its supported and safe too  :-)

(since it seems safe so far)

Agreed.

(no need to go down the RoR path  ;-)

Dockimbel: the alias "/" %x.r works too. beautiful.

Good! :-)

Should the following .rsp script work and deliver something like 
... <p>123</p> ...

<html>
  2   <head>
  3     <title>Test</title>
  4   </head>
  5   <body>
  6     <p>
  7       <%= ajoin collect [repeat i 3 [keep i]] %>
  8     </p>
  9   </body>
 10 </html>

(sorry, ignore the line numbers)

I tend to use COLLECT a lot in REBOL scripts, but it seems it can't 
be used with Cheyenne.

Which Cheyenne version are you using?

All I get is