-/* $Id: httpd.js,v 1.35 2005/07/09 06:42:09 mmondor Exp $ */
+/* $Id: httpd.js,v 1.36 2005/07/09 06:48:17 mmondor Exp $ */
/*
* Copyright (c) 2005, Matthew Mondor
*
* TODO:
* - See what to do for HEAD and PUT
- * - Think about how I'll handle invokation of scripts. I'll most probably
- * need to eval() them initially and cache them once evaluated, until
- * modified, and to invoke them prior to pre-evaluation multiple times
- * as needed. Possibly that these scripts could simply define an object
- * with an entry point or such. At worse I'll need special a C support
- * object to implement this, which would at necessary use another context,
- * possibly persistent.
- * Hmm I could perhaps also do some test, where an application would all
- * be loaded, and their functions called on a vhost based on paths,
- * if path not handled/found, fallback to static pages processing...
- * There shouldn't be more than a single application per vhost anyways.
- * We would handle session management, as well as provide user applications
- * with a document root to access their http vars...
- * - Will also need to take care to never allow uploading js scripts once
- * we allow their server-side execution.
- * - After trying a few tests, it appears that using eval() will be
- * unpracticeable, and unsafe. I will need to add a new C native object
- * to allow javascript to load/preload scripts and launch their execution
- * in a separate context, with the wanted variables attached to the
- * subcontext's root. In the case of a single embedded dynamic application,
- * I could eval() in the code to include it once, and invoke its functions
- * when certain paths are invoked.
* - Possibly limit rate of connections per address like I did in
* mmftpd/mmsmtpd/mmpop3d/mmspawnd, a requested feature of 3s4i.
* If enabling this, it probably should be per-vhost configurable.
* I'm not sure HTTP protocol is well suited to this type of limiting,
* some testing will be required.
+ * - Provide a function to scripts to redirect to another page.
+ * - Maybe provide automatic cookie retry page.
+ * This could be done by displaying a page with an auto-reload meta-tag
+ * when no cookie was received from the client. The client would reload
+ * the page, and if sending a cookie, wouldn't get this page again.
+ * On failure to return the session cookie, a loop would ensue reloading
+ * that page.
*/
* Server identification
*/
SERVER_VERSION = 'mmondor_js_httpd/0.0.1 (NetBSD)';
-SERVER_CVSID = '$Id: httpd.js,v 1.35 2005/07/09 06:42:09 mmondor Exp $';
+SERVER_CVSID = '$Id: httpd.js,v 1.36 2005/07/09 06:48:17 mmondor Exp $';
Repositories / mmondor.git / commitdiff