Re: HTTP request handler / middleware SRFI
Peter Bex
(07 Apr 2019 08:39 UTC)
|
Re: HTTP request handler / middleware SRFI Arthur A. Gleckler (07 Apr 2019 23:19 UTC)
|
Re: HTTP request handler / middleware SRFI
Peter Bex
(08 Apr 2019 08:09 UTC)
|
Re: HTTP request handler / middleware SRFI
Arthur A. Gleckler
(08 Apr 2019 17:49 UTC)
|
Re: HTTP request handler / middleware SRFI Arthur A. Gleckler 07 Apr 2019 23:19 UTC
Peter Bex <xxxxxx@more-magic.net> writes: | On Sat, Apr 06, 2019 at 01:20:38PM -0700, Arthur A. Gleckler wrote: | Maybe I just didn't try hard enough :) In my implementation, it would just be a trie deletion operation. |> Shuttle is multi-threaded (per request), | | Yeah but that means each thread serves the same application, right? A single thread accepts requests, but each request is farmed off to a separate Scheme thread for handling. | Perhaps the dispatch table can be a (wrapped) first class object. Something like: I see. Yes, that's a reasonable way to support both approaches. | Having something like this would make routers composable, so you could | register a router ("mount" it) underneath a different path in a larger | router: Yes, that would be nice. | Maybe it's overkill; you can always check the headers inside the handler for the route as long as you have access to the request object. I agree. If one needed to handle a particular header across a large set of paths, one could take care of that earlier in the handler chain. In the handler chain, would it be possible for an earlier handler to amend the behavior of later handlers in the chain rather than either handling a request or not? It would be nice to be able to install a authentication handler, for example, early in the handler chain, and rely on it to enforce authentication on all later handlers. | The main reason I think this would be tricky is that, at least in Spiffy, the low-level interface requires one to send the headers first, and then you can start writing the body. Of course if you do it that way you have to set the transfer-encoding header first, otherwise you can't chunk the content. But if your handler returns a writer and a set of headers, then the server itself can take care of that ordering, and it can add further headers as necessary. | That means the port you pass to the writer needs to know if it should | "auto-chunk" or just pass on the data as-is. The port can buffer enough data to decide whether to chunk, then either pass the buffered data straight through or chunk it and everything that follows. |> Does anyone successfully use Range requests? They always seemed impossible |> to fit nicely into any kind of general framework. | | Maybe ignore for now. Yes, let's do. I've added that and some other notes from this discussion to our notes page.