World: r3wp
[!Cheyenne] Discussions about the Cheyenne Web Server
| older newer | first last |
| Dockimbel 20-Apr-2011 [9971] | 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. | |
| Maxim 20-Apr-2011 [10003] | if you have all the setup and scripts, I have a mac machine running 24/7... it could easily grab the lates svn and dump the build where you want :-) |
| Dockimbel 20-Apr-2011 [10004] | No time tonight to setup the automated builds, will do that tomorrow after finishing 8/16-bit support in Red/System. |
| onetom 20-Apr-2011 [10005] | thx for not disappearing in the depths of ur cave without a word ;) my jsondb works with angular now thru cheyenne, btw. no delete though, but not a big issue yet. |
| Kaj 20-Apr-2011 [10006] | Ditto. Doc seems to work harder on Cheyenne while taking on Red. Maybe we should come up with a third major project for him ;-) |
| Dockimbel 21-Apr-2011 [10007] | If you can provide me a solution to avoid sleeping, why not. ;-) |
| Kaj 21-Apr-2011 [10008] | I've been working on one, but I still need to debug it. The current method causes crankiness |
| Maxim 21-Apr-2011 [10009] | my take on sleep : The most useful way to waste time ;-) |
| Kaj 21-Apr-2011 [10010] | I guess you're forced to that conclusion if you have kids :-) |
| Maxim 21-Apr-2011 [10011] | hehe |
| Kaj 21-Apr-2011 [10012] | I don't even consider it wasted, because I know my brain programs on while asleep. At dawn, it will often have worked out yesterday's problem. The question is whether the code input of Doc's extra project can fit in his waking time |
| Maxim 21-Apr-2011 [10013x3] | yeah, I know... I have 4 batch cores (which is why I often work as quickly on 4 projects as some do on one :-) |
but when the problems are complex, the night sleep doesn't fill up the whole time slot. i.e. the solution is resolved and there is still a lot of batch time left. | |
btw folks, a funded, cheyenne-related project I'm working on has been green lit for public release. I'll be doing a full announcement tomorrow on what it is, and possibly even a prototype code release. :-D | |
| GrahamC 22-Apr-2011 [10016x2] | give us a hint |
a small bone will do | |
| Maxim 22-Apr-2011 [10018] | web api |
| Dockimbel 22-Apr-2011 [10019x2] | FYI, I'm working on setting up automated Linux builds for Cheyenne. |
Automated builds are now up and running (Linux only): http://cheyenne-server.org/download.shtml | |
| older newer | first last |