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.