From 1b60f4b310419f315433b1c83ff1e7e035824f8b Mon Sep 17 00:00:00 2001 From: Laurent Bercot Date: Sat, 4 Jul 2026 04:35:14 +0000 Subject: ETags status: won't support, FastCGI status: supported Basic Auth status: still maybe --- doc/future.html | 34 ---------------------------------- 1 file changed, 34 deletions(-) (limited to 'doc') diff --git a/doc/future.html b/doc/future.html index fc98132..9636534 100644 --- a/doc/future.html +++ b/doc/future.html @@ -50,39 +50,5 @@ places in tipideed. That was more complexity than I wanted for an initial release; it's not urgent, it can wait.

-

ETags

- -

-ETags are -unique identifiers for resources that clients can use to cache data, and only -download resources they do not have. Like ranges, ETags support can save bandwidth. -

- -

- The problem is that creating ETags is pretty resource-intensive on the server -side. You have to maintain an ETag database, and update it any time a document -changes; alternatively, you have to dynamically hash a whole resource before -deciding if you're serving it or not. Both paths are riddled with traps and -design challenges, and neither is appealing to a server like tipidee aiming at -simplicity and efficiency. ETag support may come one day, but it won't be soon. -

- -

FastCGI

- -

- If tipidee compares to big Web servers performance-wise, which is the expectation, -it is quite possible that the performance bottleneck becomes the CGI protocol -itself, i.e. the need to spawn an additional process for a dynamic request. -In this case, it would be useful to support other methods of communicating with -dynamic backends. -

- -

- A module system, or embedding language-specific support into -tipideed, is out of the question, because it goes against -the design principles of tipidee; however, FastCGI support sounds like a possible -path to more performance. -

- -- cgit v1.3.1