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

onetom
19-Apr-2011
[9953]
regarding the Expect: 100-continue, i don't have any other realistic 
usecase other than this is the default behaviour of curl...
BrianH
19-Apr-2011
[9954]
In APPLY, the QUOTE function is added to the constructed block containing 
the function call. If you don't do something fancy with that function, 
no rebinding is needed. That function should really be protected 
in the runtime though; a *lot* of runtime code absolutely depends 
on these low-level control functions to behave *exactly* as they 
are expected to. Same goes for ALSO.
onetom
19-Apr-2011
[9955]
personally, i never had to use such negotiations which wouldn't accept 
a request..
BrianH
19-Apr-2011
[9956x2]
There are no other functions than those 3 that were added in the 
last 3 versions that call DO explicitly. The rest of the functions 
that call DO explicitly were in 2.7.5, so R2/Forward additions don't 
apply.
4, including COLLECT :)
Kaj
19-Apr-2011
[9958x4]
I'm trying the latest binary version of Cheyenne. I've added fast-rebol-cgi 
to the globals, but the conf-parser log says this is invalid. How 
is this keyword supposed to be used?
show.cgi stays blank. trace.log gives me this, which I wouldn't expect 
in a Linux build:
20/4-04:00:21.407196-[CGI] Error:/bin/bash: c:devsdktoolsrebol.exe: 
command not found
I took the extra files from the 0.9.20 source
onetom
20-Apr-2011
[9962x5]
Kaj: just change the 1st line of show.cgi to point to the right rebol
we were talking about this 2 days ago w Doc and i even wrote a script 
which finds the right exe and patches the 3 example cgi files
hm... how is the DELETE method supported? im getting 405
mod-static.r 74:		unless find [HEAD GET POST PUT DELETE] req/in/method 
[

doesn't help alone. im getting 404 now :/
we are trying to interface cheyenne with the angularjs.org - fyi

luckily we can set a deleted attribute for now if we really want 
to delete something, but that's just a workaround
Dockimbel
20-Apr-2011
[9967x5]
fast-rebol-cgi: I guess I forgot to declared it as a config keyword, 
I'll fix that now.
show.cgi: I can't provide a CGI script that would work out of the 
box on all OSes and every possible local configuration, so I've left 
it as-is for users to adapt the shebang line. Using onetom's setup 
script might be the best solution, I'm thinking about integrating 
it in the Cheyenne sources package.
Kaj: fast-rebol-cgi issue fixed in revision 131. If you need a new 
Linux binary, I can build you one (just let me know if you prefer 
a /Pro or /Cmd version).
onetom: DELETE is not supported by default, but it can be easily 
hacked in as you did (note to myself: add a config option to enable 
additional HTTP methods).
No 404 here:
>> p: open/no-wait/direct tcp://localhost:80
>> insert p "DELETE /show.rsp HTTP/1.0^/^/"
>> probe copy p
{HTTP/1.1 200 OK
Server: Cheyenne/0.9.20
Date: Wed, 20 Apr 2011 11:06:16 GMT
Content-Length: 520
Content-Type: text/html
Connection: close
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: -1

<HTML>
<HEAD>
^-<TITLE>RSP Test Page</TITLE>
</HEAD>
...
onetom
20-Apr-2011
[9972x2]
ok, let me dig deeper then. meanwhile since u r planning a new release, 
can u "enable" the DELETE method too?
the changelog can say: preliminary, dumb, DELETE method "support"
it's still better than nothing
pleeeease :)
Dockimbel
20-Apr-2011
[9974]
I think that the config option is a better way to handle it. I prefer 
returning a 405 error code to online web scanners for the 99% of 
Cheyenne servers that don't need DELETE.
onetom
20-Apr-2011
[9975x2]
onetom ~/rebol/delete $ cat httpd.cfg 
modules [ internal extapp static rsp alias ]
globals [ listen [8888]    bind RSP to [ .r ] ]
default [ debug root-dir %./ alias "/test" %test.r ]

onetom ~/rebol/delete $ cat test.r 
<% print request %>


onetom ~/rebol/delete $ rm chey-*.log; rebol -qws ~/rebol/cheyenne-server-read-only/Cheyenne/cheyenne.r 
-w 0 -vvv


onetom ~/rebol/delete $ curl -X DELETE -D- http://localhost:8888/test
HTTP/1.1 404 Not Found
Server: Cheyenne/0.9.20
Date: Wed, 20 Apr 2011 11:14:04 GMT
Content-Length: 53
Content-Type: text/html
Connection: close

<html><body><h1>404 Page not found</h1></body></html>


>> p: open/no-wait/direct tcp://localhost:8888
>>  insert p "DELETE /show.rsp HTTP/1.0^/^/"
>> probe copy p
{HTTP/1.1 404 Not Found
Server: Cheyenne/0.9.20
Date: Wed, 20 Apr 2011 11:17:34 GMT
Content-Length: 53
Content-Type: text/html
Connection: close

<html><body><h1>404 Page not found</h1></body></html>}



u were doing 1.0 DELETE request though, but it didn't make any difference.

onetom ~/rebol/cheyenne-server-read-only/Cheyenne $ svn up
U    mods/mod-action.r
Updated to revision 131.
or is it better to paste such bigger chunks somewhere else?
email it? or pastebin.com?
Dockimbel
20-Apr-2011
[9977x3]
pastebin is a better option
A few remarks about your config:
- modules [ internal extapp static rsp alias ] : it is missing 'action 
module which is required for external handlers (RSP and CGI)
onetom
20-Apr-2011
[9980]
oops, i forgot the /test from the url
Dockimbel
20-Apr-2011
[9981x2]
- globals [ listen [8888]    bind RSP to [ .r ] ] : it should be 
BIND-EXTERN (for worker handler) instead of BIND (main process internal 
module,  like SSI). Your .r scripts are anyway working because .r 
scripts are supported as alternative to .rsp since 0.9.20
BTW, listen 8888 should word (block is only required when several 
listening ports are specified)
onetom
20-Apr-2011
[9983x3]
true, forgot about that
so since 0.9.20 .r is bind-externd to RSP?
does it take precedence over bind RSP too? because otherwise my thing 
seemd to work... even .r reloading was happening and all that
hmm.. this separated example doesnt work indeed
Dockimbel
20-Apr-2011
[9986x2]
so since 0.9.20 .r is bind-externd to RSP?

 Yes, but in a particular way: .r are not considered "templates" but 
 plain REBOL scripts (with a REBOL header). So, if you want to use 
 RSP templates with .r, you should add a BIND-EXTERN directive (untested, 
 so I'm unsure if it would work)
I need to check the code for how .r are precisely handled, I coded 
that a few months ago and almost forgot about it.
onetom
20-Apr-2011
[9988]
if u note it down here tonite i will shovel ur words into the cheyenne 
wiki
Dockimbel
20-Apr-2011
[9989]
I need to work on Red this afternoon, I'll do a pass on things to 
add in Cheyenne tonight.
onetom
20-Apr-2011
[9990x2]
the binary works, the source doesn't...
the source version just gives 404 to everything
Maxim
20-Apr-2011
[9992]
can anyone get a login for the cheyenne wiki?


I'd really like to put down my trials and errors of building my own 
cheyenne mod (with handler), so that others may benefit of knowing 
the few little caveats which can make the whole thing fail .... 
maybe do something like a step by step tutorial to begin with.


I'd also like to document all the phases of each internal layer of 
cheyenne (there are many), so that we can more easily navigate the 
code, knowing what we are doing and what other phase is part of each 
type of mod,extension, service, etc.   often, we see just one or 
two parts of a system implemented per module and its hard to get 
the whole picture.   


ironically, looking at the base objects is also hard to do, since 
there is so much "internal" code that it gets REALLY hard to understand 
what is internal, what is "interface" and what is provided as helper 
funcs for your own systems to use.  Add the fact that there are many 
layers sitting over each other, some layers which aren't actually 
layers of code, but layers in the "chain of command" and various 
phases.


now that I've made sense of a *portion* of this, I think I'm well 
placed to start documenting this.   I think that having a complete 
api reference for cheyenne would be really good for adoptance.


It would allow many of us to simply create integrated tools which 
just drop into cheyenne.  (like remark)
onetom
20-Apr-2011
[9993]
~1.5yr ago i backed off from cheyenne because i could build a configuration 
service from the mini webserver on rebol.org. it's just ~60 likes 
of code and handles get only
Henrik
20-Apr-2011
[9994]
My main weakness with Cheyenne is the debugging of webapp handlers. 
I simply can't tell what's going on and why they won't run in my 
webapp.
Kaj
20-Apr-2011
[9995x5]
show.cgi: I can't provide a CGI script that would work out of the 
box on all OSes and every possible local configuration, so I've left 
it as-is for users to adapt the shebang line. Using onetom's setup 
script might be the best solution, I'm thinking about integrating 
it in the Cheyenne sources package.
Odd, I don't remember having to fix it before, and I didn't formalise 
it in my build scripts, but thanks
Kaj: fast-rebol-cgi issue fixed in revision 131. If you need a new 
Linux binary, I can build you one (just let me know if you prefer 
a /Pro or /Cmd version).
Pro please, but no hurry. If you can combine it with other changes, 
please do
Ah, wouldn't it be that the shebang line doesn't need to be adapted 
once fast-rebol-cgi is enabled again?
Dockimbel
20-Apr-2011
[10000x3]
Right, in fast-rebol-cgi mode, the shebang line is not processed.
Also, I might have changed the shebang lines in CGI demo scripts 
to Windows format for local testing without reverting them to UNIX 
format once done.
I think that I'll setup some automated nightly builds, but probably 
only for Linux target as a start. I could later add Windows support 
(I have a Windows box running 24/7), but MacOS will be missing.