World: r3wp
[!Cheyenne] Discussions about the Cheyenne Web Server
older newer | first last |
Henrik 19-Apr-2011 [9915] | I'm having a strange problem with one virtual-root that works and another that doesn't. The one that doesn't simply sends back a 404. |
Dockimbel 19-Apr-2011 [9916] | Can you show me the config definition for these two webapps? |
Henrik 19-Apr-2011 [9917x2] | privately |
What's the best way to debug app-init.r now? I can't see whether a bug happens or whether it runs ON-APPLICATION-START at all. | |
Dockimbel 19-Apr-2011 [9919x2] | Use 'debug/probe or 'debug/print to emit debug logs in %trace.log file. |
If an error is caught in 'on-applicaion-start, it will appear in %trace.log. | |
Henrik 19-Apr-2011 [9921] | nothing shows up, so I guess ON-APPLICATION-START is never run. |
Dockimbel 19-Apr-2011 [9922] | probably (see my private message) |
onetom 19-Apr-2011 [9923x6] | i have an rsp like this: <% probe delta-time [ ... switch request/method [ get [...] post [...] ] ... ] %> if i make a GET, it's fast: $ time curl -s -D- http://localhost:8080/docs/rfq3 >/dev/null 0:00:00.003815 real 0m0.026s if i make a post, the rsp part is still fast, but the overall request is damn slow (even consequent requests too): $ time curl -d @xxx -D- http://localhost:8080/docs/rfq3 0:00:00.004595 real 0m2.034s |
so what is this 100 fold difference between GET and POST? | |
is it just curl? i will try from rebol 1st | |
from rebol, it's okay... >> delta-time [read/custom http://localhost:8080/docs/rfq3 reduce ['post read %xxx] ] connecting to: localhost == 0:00:00.034002 | |
it has something to do with the connection keep-alive | |
curl --http1.0 ... is fast | |
Maxim 19-Apr-2011 [9929x2] | yes, the http connection will not close until it times out. if the curl command line waits for ip close to return, its possible that is what is happening. |
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 [9962x3] | 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 | |
older newer | first last |