HTTP Functions

[Jeff]

Lutz, could you expose the functions that parse HTTP headers? Perhaps have them build a simple assoc list for us? That would make writing servers *much* easier.

[Lutz]

This has already been done. The new 'command-event' function not only intercepts the interactive newLISP command line but also HTTP requests coming into newLISP when started in server mode. You can then parse and change these requests before they get passed on to the server.

There is an example about this here:

http://newlisp.org/download/development ... mand-event

[Jeff]

So what will the callback function receive exactly? I am talking about the functions that actually parse HTTP headers when newLISP is in http server mode. I would ideally like to use the built-in parsing routines and then deal with the parsed results myself.

[Lutz]

So what will the callback function receive exactly?

the GET, HEAD, PUT, POST or DELETE HTTP request line. I.e. for:

Code: Select all

http://site.com/form.cgi?name=joe&pass=secret

you would get the HTTP rquest line in command-event:

Code: Select all

GET /form.cgi?name=joe&pass=secret

and could change it before passing it on to newLISP server.

Then newLISP's internal parsing routine break it up into, the CGI file-path and the query string.

Currently the headers: Content-length, Pragma: append, Host, User-Agent and Cookie are recognized. Environment variables are filled for HTTP_HOST, HTTP_USER_AGENT and HTTP_COOKIE.

The main purpose of newLISP server mode is to satisfy requests for:

Code: Select all

(net-eval ...)
(save "http:// ... )
(load "htttp:// ... )
(read-file "http:// ... )
(write-file "http:// ...)
(append-file "http:// ...)
(delete-file "httP:// ...)

... in a distributed net of newLISP server and client nodes communicating with each other, and in a firewalled closed environment.

The fact the newLISP server mode can be used as a simple web-server is basically a by-product of the distributed-net functionality. Enhanced by just a few little things, like setting a few environment strings and CGI processing, to give it basic web-server fuctionality. I am reluctant to built anything more into it. Its a slippery slope, there are very good web-servers already, and doing everything ;-).

[Jeff]

Yeah. I just thought it might be nice to have acess to the built in function that actually does the string-parsing on the HTTP header lines. That way, there is built in support for building an http server. Especially if the interpreter can handle chunking.

That would be a neat addition to the other tcp/udp server functions. It wouldn't need to do anything but parse the header and return a list of something like '(("method" "POST") ("path" "/foo") ("protocol" "HTTP/1.1") ("key" "value") ...). That would make writing http servers much simpler and much faster, since the parsing would be a compiled function.

[rickyboy]

That would be a neat addition to the other tcp/udp server functions. It wouldn't need to do anything but parse the header and return a list of something like '(("method" "POST") ("path" "/foo") ("protocol" "HTTP/1.1") ("key" "value") ...). That would make writing http servers much simpler and much faster, since the parsing would be a compiled function.

Can't you write your own shared library of routines to do these things for you (say in C)?

I agree with Lutz: it's a slippery slope.

[Lutz]

HTTP request and header lines are trivial to parse in newLISP. Just roll your own httpd server ;-). There was one shipped like this earlier in newLISP source distributions, you will find one in newlisp-9.0.0/examples/httpd it has only about 200 lines of code and still did CGI.

[Jeff]

I *have* my own routines for this. I just thought it would be nice to have a built-in.