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

Maxim
19-Apr-2011
[9930]
there are probably ways control this via some curl command line options?
onetom
19-Apr-2011
[9931x2]
i was trying an explicite response/set-header 'connection "close", 
but it didn't help..
see the --http1.0 option above. with that there is no Connection: 
keep-alive  header sent  (or maybe there is, but in HTTP/1.0 mode 
it is ignored)
Maxim
19-Apr-2011
[9933x2]
it shoudn't send it.  the servers are always free to implement more 
headers than the spec.

also realize that if you use http 1.0 there are no virtual hosts!! 
supported so its a bit deal.
bit = big
onetom
19-Apr-2011
[9935]
with the --no-keepalive option, this magic 2seconds delay is still 
there
BrianH
19-Apr-2011
[9936]
If you haven't figured out the COLLECT rewrite yet, let me take a 
look.
onetom
19-Apr-2011
[9937x2]
hmm... does cheyenne handle the Expect: 100-continue header?

i couldn't really find any signs of it. the http-responses mentiones 
the code 100, but that's all, im afraid
Here is a workaround (by raping curl):


$ time curl -H 'Expect:' -d @xxx -D- http://localhost:8080/docs/rfq3
real    0m0.082s
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)