Thoughts about Jester and practical header handling
## Thoughts about Jester and practical header handling

I looked into the code and think that I would like to contribute some changes to add functionalities based around headers. 

But at first: I am not sure if that is really in the scope of Jester (and where to stop). I don't know "sinatra". I just develop our companies own framework since 1997 and it is opinionated but very flexible about how stuff works. It evolved 18 years and as such is still very compact and backward compatible to the version from 10 years ago. Which I mention because "the scope" of Jester could be equal to that, which is based on practical experience with many mostly database focused projects.
### Some Targets

My main targets would be extending the current code in a way that headers are not something which is handled "just in the end" of handling a request. 

I also believe that "status code" has not really a lot to do with the content you send. Many "error code" responses could have a nice HTML page or for example json content. 

As another example: There are a lot of different and meaningful ways of redirection besides 303 so this needs to be a parameter (with a sensible default).

Content-Type... well I love to server images, csv, pdf, json dynamically generated through the framework. HTML is just one thing which will profit from extended header handling (for example it is really nice to have e-tags to decide if an image needs to be recreated).
### Header handling

Basically headers should be "collected" throughout the processing and there should be some practicable functionality implemented around HTTP "caching" (which does not cache anything). Disabling the default header handling should be optional, as there are always sensitive defaults!
#### content related
- content-type is invaluable  (should just "default" to text/html)
- compression gzip and deflate come to mind
- languages / encodings and other stuff maybe later...
#### caching related
- if-modified-since: should by default work for static sources
- last-modified: should be send per default for everything
- expires: should be easily to set (like expires in timeframe or at given time)
- A "nocache" mode (absolutely no!) could be implemented as some "magic" headers
- e-tags: could be available with some nearly "raw" helpers and as functions about the content response. Later would not safe time for computing of the answer but skips the transfer (useful to safe bandwith)
### Conclusion

If those changes are in the scope for Jester I can try to improve the headers and some other stuff. I am not sure how much time I can invest because I can't move our projects to Jester and Nim. Mostly because our codebase is just to big. But there may be a way to "integrate" stuff which I don't see right now. Besides that I may find a project which could be based on jester in the near future.
