ekmartin / sprocket Goto Github PK

Should create a handler that can be attached to a base path which would serve files from there.
Could look something like:
(add-handler 'GET "/static" (static-handler "directory")) which would then result in requests such as /static/file.txt returning file.txt from directory.

Right now if multiple handlers try to a write a response they'll all be sent.

#17 only adds support for text files (HTML etc.), not images and so on.

There's some random displays and similar laying around for debugging, should remove them before handing in (e.g. in httpio.scm).

After we have support for generic middleware we should create a JSON body parser and response serializer. The former would take in a request with a JSON body and parse it to a Scheme data structure, while the latter would take a Scheme data structure and serialize it to a JSON string before it's sent back to the user.

https://github.com/joeltg/json.scm

Also inspired by https://github.com/dmac/spin, for request handlers that return 200 with no new headers and just a response, we could turn this:

(define (handler req)
  '(200 () "Hello World!"))

into just

(define (handler req) "Hello World!")

Just a reminder before we submit.

Similar to #4, we could create a generic middleware that would parse HTTP form requests into a data structure. There might be a parser for this in mod-ssp already.

Similar to #7, it would probably be useful for middleware and handlers to "tack on" e.g. headers to the response object, so that the final response is a cooperation between all the handlers - instead of just the result of calling one of them. This is also how most web servers work, like Express.

Instead of making the developer create handlers by doing (add-handler "POST" "/path" (lambda ())) we could for example define helper methods like (post "/path" (lambda()).

Inspired by https://github.com/dmac/spin

All of the useful procedures should log what they're doing when logging is enabled (see #9 for how logging could be enabled).

Could set the Content-Type header to the MIME type when serving static files, e.g. image/png for .png files and so on.

Browsers are pretty good at guessing the type, so not horrible if we don't, but there's probably some mime stuff lying around somewhere in scheme if we want to.

There's probably some mit-scheme test framework we could use for this.

Not a big deal, but if we're still including httpio.scm when we deliver the project we should probably change the license to GPL-2 or GPL-3, since mit-scheme uses that and the GPL enforces that all projects that modify its original source needs to use GPL as well.

https://github.com/tali713/mit-scheme/blob/master/src/runtime/httpio.scm#L1-L25

The current solution just matches the URL one to one. We should add support for features such as matching variables, i.e. /houses/:houseNumber. Most web servers do this by letting developers define a URL string, and then parse that, but we don't necessarily have to do that. Could do something more schemey with pattern matching etc.

Most web servers allow request handlers to read useful information from the request, and even change it if they'd like to. Right now our handlers are just passed the original HTTP request object - we should probably wrap this in something.

This relies on #7 really, but we could let the handlers access the user's cookies as a Scheme data structure (e.g. an alist). There's some cookie parsing procedures in src/ssp/mod-lisp.scm in Scheme we can borrow.

Should build a web application that makes use of Sprocket.

This is definitely a stretch goal, but if we have time we could allow request handlers to return HTML with a templating data structure similar to the nested lists e.g. Racket uses:

(send/suspend
 (lambda (k-url)
   (response/xexpr
    `(html (head (title "Enter a number"))
           (body
            (form ([action ,k-url])
                  "Enter a number: "
                  (input ([name "number"]))
                  (input ([type "submit"]))))))))

Similar to the redirect procedure this should call read-file on the given path and return `(200 () ,content) where content is the result of read-file.

Right now the handlers are always terminal, i.e. they have to return a response.
We should add support for handlers that appear in the middle of the request chain, i.e. middleware. One way to do this would be to define handlers that don't return anything as middleware, and then continue until one of them actually do return something.

(create-server) could for example take in an association list with config options and values.

Should probably be bound to the request handling with bind-condition-handler. There should be a default handler that returns a 500 response if the server goes bananas.