Basic Web Server¶

• Serves static files from the selected file system. This is a compile-time setting, and a typical configuration supports gif, jpg, jpeg, ico, png, zip, gz, tar, txt, pdf, htm, and html.
• It is designed to be small, thereby better supporting the limited resources of an embedded environment.

Advanced Web Services¶

• Serves dynamically generated pages, where your software registers for a path, and then everything to that path activates your handler. Your handler then defines the header and body response.
• Dynamic handlers can process GET query parameters (e.g. /dyn1?sky=blue&grass=green).
• Dynamic handlers can process POST query parameters, as delivered from submission of a form.

Run-Time Configurations¶

• File System Support - using either the "local" file system supported by the magic chip, or from either an SD-Card or a USB flash drive.
• Configurable to the maximum number of dynamic handlers (minimize memory requirements).
• Configurable to the maximum number of name=value pairs for dynamic handlers (minimize memory requirements).

Compile-Time Configurations¶

• Default filename for URL ending in '/' - default is 'index.htm'.
• Configurable buffer sizes permit minimizing RAM requirements.
• Configurable header response information.
• Configurable for which serial port is used to communicate to the WiFly module.
• Improved security option - to disable telnet access.

Diagnostics¶

• API to determine the largest header (to more efficiently size the buffers).
• API to gather the run-time characteristics - header processing time and content delivery time.

Limitations / Constraints¶

Wifly Limitations¶

• Single thread - it doesn't respond to overlapping requests (e.g. an embedded image may be requested before the main page completes transfer - the request is lost and the image not shown).
• Single client - goes along with the single thread, but it doesn't support more than one client at a time.

Smart-Wifly-WebServer¶

• Dynamic memory allocation - it does use dynamic memory allocation, which would be discouraged/avoided in many embedded systems. Here it uses it in parsing a request and it releases those resources upon completion of that request. If there is no other dynamic allocation that persists beyond a transaction, it should not cause memory fragmentation. Note that with multi-threading (if this is implemented with an OS), you then have race conditions that could cause fragmentation.