World: r3wp
[!Cheyenne] Discussions about the Cheyenne Web Server
| older newer | first last |
| Dockimbel 19-Apr-2011 [9939x3] | HTTP code 100: not supported, if you have a (not obscure) use-case for that, I might add support for it. |
Keep-alive: IIRC, Cheyenne doesn't honor the "Connection: close" case with HTTP1.1. | |
BrianH: I've found a workaround for COLLECT (just replacing DO by *DO which refers to the native function in RSP environment). Can you tell me if there are other recently added mezzs (from R2/Forward mainly) that rely on DO in their implemenation? | |
| Maxim 19-Apr-2011 [9942] | the module stuff, probably. |
| Dockimbel 19-Apr-2011 [9943x2] | I would need to patch them one by one when used in RSP. |
(should be a one-line patch like for COLLECT, so not a big deal) | |
| BrianH 19-Apr-2011 [9945x2] | APPLY and MAP-EACH, so far. |
Both of them do a block though. | |
| Dockimbel 19-Apr-2011 [9947x2] | Thanks, will patch them too. |
Oh, if it's a block!, then it should work in RSP. | |
| BrianH 19-Apr-2011 [9949x2] | IN-DIR also does a block. |
None of need rebinding though, as they get all of their non-locally-bound words from the calling context, so it might be worth patching them anyways. | |
| Dockimbel 19-Apr-2011 [9951] | Will look into that. |
| onetom 19-Apr-2011 [9952x2] | hmm... it was more troublesome to include the R2/Forward as we thought... :/ |
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 |
| older newer | first last |