Added Features.

[paul-1]

Yes, I've seen issue #17 and others. But I'm not the one to do major rewrites from scratch, and I liked how this server was small, and could both server files and cgi-ish content. The files being served are mainly css and js and some small graphics. These also benefit from having the ability to have cache control. The forms and table based content became to large to send as a single string body so I added the ability to send data with chunked transfer encoding.

I looked at ampule, but TBH, I had already figured this out here, and I didn't need the extra dependencies either. This is a collection of a few added capabilities. All of the additions should not break current api implementations, just extends the capabilities. Feel free to accept, make comments or just throw away.

This also solves the issue #21 that I was having.

[paul-1]

I meant to mark this as draft.....for conversation. Plus I see I have some pylint issues to cleanup if there is some desire to continue.

There still is an issue with the route decorator. On some form submissions, it is failing to find the correct route.
I had a version that was just doing a string truncation when the request arrives that was working.

[paul-1]

Well that should clean up the known issues. Not sure how I missed the pull request standards.....sorry for that.

[dhalbert]

Could some folks test this? Thanks.

@paul-1 Could you fix the merge conflict? Thanks.

[paul-1]

I was looking that the refactoring that happened in #25 the other day. The timeout option is now in the base, but I'll rebase the rest of the functions.

[anecdata]

@paul-1 Can you briefly describe the use case for the Cache-Control? As I read it, it's purely informative from the server to the client (and possibly any intervening servers), so, for example, the client may choose to hold off on making another request until max-age but the server may still serve up new content to a client still within the freshness interval?

[paul-1]

The use case is to allow cache for files like css, js, favicon.ico and other static content that you might want to serve as a part of your dynamic web page. The default cache for a file being served is one week.

Full featured web servers would send a response header for the file, that includes the last modified date. While the os module does allow for finding and setting the timestamp on a file, setting the time felt much too complicated for non connected devices. Using the cache control header we let the client keep track of dates before the cache becomes stale. Dynamically generated data using a route decorator does not get a cache header by default. If a log file is being served, then simply override the default cache setting by using a route for the file without defining a cache..

def base(request):
    return HTTPResponse(root_path='/wwwroot', filename='/somelogfile.txt')

or increase the default cache

def base(request):
    return HTTPResponse(root_path='/wwwroot', filename='/banner.png', cache=31_536_000)

[anecdata]

Tested Cache-Control header and chunked responses with browser, curl (also curl --raw to see the chunks), and from a CircuitPython 8.0.0-beta device. LGTM... thanks @paul-1 !

[anecdata]

@dhalbert Any further thoughts on this, or good to merge?

[dhalbert]

If others have tested, it's fine to merge. Thanks.