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 Peter Bex 08 Apr 2019 08:09 UTC
On Sun, Apr 07, 2019 at 04:19:05PM -0700, Arthur A. Gleckler wrote: > Peter Bex <xxxxxx@more-magic.net> writes: > | Maybe I just didn't try hard enough :) > > In my implementation, it would just be a trie deletion operation. I see. That should work fine. > |> 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. I mean if the dispatch table is a global, all threads would share it. > 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. In Spiffy, you can parameterize (or mutate, but that's not recommended) some settings around the call to the "continue" procedure. So, a handler does not need to actually send a response *or* call the continue procedure; it can do things. > | 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. Okay, should work. > |> 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. Thanks! Cheers, Peter