Newlisp-Apache-CGI Issues Again

Started by dukester, March 26, 2019, 06:28:10 AM

Previous topic - Next topic

dukester

PS C:binnewlisp> newlisp -v

newLISP v.10.7.1 64-bit on Windows IPv4/6 UTF-8 libffi.



Running Apache2.4 on a Win10 box.



Apache is choking - once again - on the header sent by newlisp:


QuoteContent-type' contains invalid characters, aborting request


Lutz fixed a similar issue back in 2015, but it seems to have re-surfaced!



This is the code used then and now:
#!C:binnewlispnewlisp.exe
(print "Content-type: text/htmlnn")

(print "<html>")
(print "<h4>CGI by newLISP v" (sys-info -2)" on " ostype "</h4>")
(dolist (e (env)) (println (e 0) " : " (e 1) "</br>"))
(println "</html>")
(exit)


Anybody know how to fix this issue?
duke

rickyboy

#1
Looks suspiciously like the ole windoze versus unix line ending issue/difference. I'd check that before moving on to anything else.



For instance, what about trying this instead? (Sorry, "I don't do windows." :)


(println "Content-type: text/html")
(println "")

Or something like that? Good luck!
(λx. x x) (λx. x x)

dukester

#2
Quote from: "rickyboy"Looks suspiciously like the ole windoze versus unix line ending issue/difference. I'd check that before moving on to anything else.

Nope! It's a newlisp issue - just like back in 2015.



I tried your suggestion, even though I knew it wouldn't work. And it didn't. Lutz will have to get involved I'm sure. Thanks anyway!
duke

rrq

#3
You might want to try the initial line Status: 200 OK

dukester

#4
Quote from: "ralph.ronnquist"You might want to try the initial line Status: 200 OK

Don't know what you mean!
duke

rrq

#5
afair, a CGI response that includes headers should have a very first line being the HTTP response status code, then the header lines, then an empty line, and then the payload.



You may omit the headers part and start with the empty line, and then the CGI runner would insert a standard header component (with a default status line).



But not all CGI runners insert a status line before headers when headers are given. For example, newlisp does insert a default status line and default headers (in its -http mode CGI runner), but possibly apache2 doesn't.



Though, I do this irregularly enough that I typically have to refer to the CGI spec's to remind myself about the nitty-gritty, and apache2 is (like most) a moving target anyhow.

dukester

#6
@ralph.ronnquist - I'm sure that you are absolutely correct. However, I've never had to do what you are suggesting. Most of my experience has been on Apache using from CL to Perl to crank out CGI stuff.  Newlisp is the only interpreter that has ever given me fits with these type of issues - given that I didn't trash that very important first line of code.



Lutx fixed this issue once. He may not want to deal with it again. I've got the very same script running just fine using CLISP2.49. I don't use -http unless I want to serve an Intranet.



thx for getting back to me.
duke

rickyboy

#7
What ralph said.  Apache 2.4 got "strict" with the header validations to mitigate vulnerabilities when used as an http proxy, e.g. this one in 2016 (interesting read too):



https://httpd.apache.org/security/vulnerabilities_24.html#CVE-2016-8743">https://httpd.apache.org/security/vulne ... -2016-8743">https://httpd.apache.org/security/vulnerabilities_24.html#CVE-2016-8743



Notice the switch where you can turn that off (although not recommended):



http://httpd.apache.org/docs/2.4/mod/core.html#httpprotocoloptions">http://httpd.apache.org/docs/2.4/mod/co ... coloptions">http://httpd.apache.org/docs/2.4/mod/core.html#httpprotocoloptions



Could that have been the reason that that code worked recently and now it doesn't?  (Switch got changed?)



I think keeping that setting to the default strict mode and going down the path that ralph suggested for your troubleshooting sounds good to me -- at least in the meantime before you hear anything from Lutz.  Again, good luck.



(If I had the same stack, I could try to recreate the problem; however. along with not being a Windows user, I'm also not an Apache user. :)
(λx. x x) (λx. x x)

dukester

#8
@rickyboy  All good stuff!  But if Apache was being a bad-ass, it would be doing so with my Perl, Python and Ruby scripts!  Even old CLISP scripts run well.  Get where I'm going with this?  ;-)



Thanks for the heads-up regarding Apache security stuff!
duke

xytroxon

#9
I think the problem is that the command-line prompt and initial copyright banner output needs to be suppressed.



Change the line:
#!C:binnewlispnewlisp.exe

To:
#!C:binnewlispnewlisp.exe -c

-- xytroxon
\"Many computers can print only capital letters, so we shall not use lowercase letters.\"

-- Let\'s Talk Lisp (c) 1976

dukester

#10
Quote from: "xytroxon"I think the problem is that the command-line prompt and initial copyright banner output needs to be suppressed.



Change the line:
#!C:binnewlispnewlisp.exe

To:
#!C:binnewlispnewlisp.exe -c

Thx!  I'll give that a shot!!
duke

dukester

#11
Nope!  No cigar! LOL
duke

Lutz

#12
Try:


(print "Content-Type: text/htmlrnrn")

dukester

#13
@lutz Thx, but that does not work either. Sorry!
duke

rrq

#14
Have you verified the byte sequence from the script, eg by running it manually and pipe its output into a file, which you the inspect with a hex code viewer? Or even perhaps like the following:
% thescript | C:binnewlispnewlisp.exe -e '(read 0 b 10000)(map char (explode b))'
Note, I don't really use windows myself, so I'm guessing about piping the output from one command (thescript) to another (the unpacking into character codes). In any case, the resulting character codes list should then begin
(67 111 110 116 101 110 116 45 116 121 112 101 ...