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