-http mode responds to net-eval

Started by rrq, April 11, 2015, 07:04:42 PM

Previous topic - Next topic

rrq

Test scenario: running newlisp in -http mode and another newlisp querying it:
1% newlisp -http -d 19001

2% newlisp -e '(net-eval localhost 19001 {(exec "ls")})'

More specifically, in the source, I can see that the batchMode logic of executeCommandLine seems buggy; it enters batchMode=2 whenever the input starts with "[cmd]", and this simply bypasses both the command event call, and the HTTP dispatch chain, also including the end case of avoiding evaluation.



I would have liked suggesting a fix, and perhaps it's sufficient to avoid entering batchMode=2 in the case of httpMode&&noPromptMode, but I'm not totally a par with all ramifications of that.



In any case, this really is a show stopper for using it as front-line http request handler.



EDIT: Possibly one can patch this by having an exiting reader-event handler:
(reader-event (fn (s) (exit)))
This simply closes the connection for any net-eval input, i.e., when the input starts with "[cmd]", and other input (esp. http requests) is processed like before.

Note that this has to be the very last thing on a server definition file.

Lutz

#1
Thanks for catching this bug. In version 10.6.3 http only mode is http only. Older net-eval clients will wait for ever, 10.6.3 net-eval clients will return nil.



http://www.newlisp.org/downloads/development/inprogress/">http://www.newlisp.org/downloads/develo ... nprogress/">http://www.newlisp.org/downloads/development/inprogress/

rrq

#2
Hmm. I just downloaded and compiled newlisp10.6.3.tgz from there, and I get
% ./newlisp -e '(net-eval "localhost" 19001 true)'        
true

I.e., the other process "./newlisp -http -d 19001" responds to net-eval.



This is: newLISP v.10.6.3 32-bit on Linux IPv4/6 UTF-8 libffi, options: newlisp -h

which I just pulled from the inrogress directory. Looking into newlisp.c it looks like "-c" (setting noPromptMode = TRUE) is subsumed by "-http" (which does the same plus httpMode = TRUE).

Lutz

#3
You must run a wrong version. Checked on Windows 7 and OSX and get either nil or a "Socket send failed" error message.



The -c mode answers to  both net-eval and HTTPrequests, but the -http mode to HTTP only. Check the relevant code in executeCommandLine() in line 1172:


if(!batchMode)
    {
    if(logTraffic == LOG_MORE)
        writeLog(command, TRUE);
#ifndef LIBRARY
    if(strncmp(command, "GET /", 5) == 0)
...
...
#endif
    else if(!httpMode) goto EXEC_COMMANDLINE;
    return;
    }
if(httpMode) goto RETURN_BATCHMODE;

There code forces closing the connection and return on httpMode after the goto:
RETURN_BATCHMODE:
    if(!daemonMode)  exit(1);
    if(IOchannel != NULL) fclose(IOchannel);
#ifndef LIBRARY
    setupServer(1);
#endif
    return;

if httpMode is on it will never execute that other code portion before RETURN_BATCHMODE.



Ps: also try other than true as expression to evaluate, e.g:
newlisp -e '(net-eval "localhost" 2345 "(+ 3 4)")'
expecting 7 as return.

rrq

#4
yes, I messed up in my downloading.



Doing it right gave me the additional source line of
if(httpMode) goto RETURN_BATCHMODE;
which makes -http be only HTTP handling, I guess.



Interestingly enough, I realized that HTTP processing is always available, with or without -http or -c. It's even available on the interactive prompt. E.g. you can type
GET /xxx HTTP/1.1
with two newlines, to trigger the HTTP request handling, and get an error response (unless file xxx is available) and then newlisp exits.



The key for me of course is the restrictive -http mode.

rrq

#5
... it appears this version has lost the HTTP_AUTHORIZATION patch.

Lutz

#6
In again:



http://www.newlisp.org/downloads/development/inprogress/">http://www.newlisp.org/downloads/develo ... nprogress/">http://www.newlisp.org/downloads/development/inprogress/

Lutz

#7
If you are concerned about security, you should also supply a conection timeout when starting a newlisp HTTP only server, e.g:

newlisp -http -t 500000 -d 80

Without the 1/2 sec timeout, it would be possible to connect without sending any request, effectively capturing the server. This could happen on purpose a because of technical problems in the client after connecting. If no request is coming the server will disconnect after the timeout and wait for a new connection.

rrq

#8
Thanks. Good point. Yes, I'll do that.

Although the particular service is not really public, it's of course publicly available. It's HTTPS by virtue of an 'stunnel' proxying to the firewalled newlisp, so I might need to think about that session timeout as well.