HTTaP uses a reduced subset of HTTP, keeping only a few essential features.
- Any HTTP compliant server must be able to understand HTTaP requests even though it can't fulfill all the requests (at worst, it replies with a 404 status)
- Any HTTP client can send a HTTaP compliant request with minimal effort. Normally, the HTTaP client is a classic web browser but wget or curl must work too.
HTTaP servers work mostly like classic HTTP servers but differ in a few ways, such as
- resource reference (naming conventions)
- caching
- no cookies
- timeout
- persistent connections
- serialisation (no simultaneous/multiple accesses)
- headers
These implementation choices come from constrains in size, speed, complexity : HTTaP must run in "barebone systems" with limited code and data memory, reduced CPU resources and lax security.
Development and support of HTTaP at the lowest level is on the server side because all the clients are meant to be HTTP compliant already. High-level development (the application's intelligence) focuses on the client side, which uses JavaScript (or any other powerful dynamic language, since Python is quite popular for example and a browser is not required) to assemble the requests and interpret the responses.
The HTTaP server must be as lean and simple as possible.
- One source of complexity is removed by not interpreting the client's request headers. Actually, none of these headers are pertinent or relevant to most of HTTaP's use cases (except Compression). This cuts a lot of work but also means there is no support for cookies. Standard authentication is impossible so HTTaP is unsecured. Any client can connect and use the resources at will. Use HTTaP only on airgapped networks.
- Another source of complexity comes from the HTTP "vocabulary" : the only supported methods are GET, POST and HEAD.
* GET reads resources (files or dynamic variables) like any usual request.
* POST writes these variables (file upload is only an option)
* HEAD is a requirement of HTTP1.1 and only minimal support is provided (because it is barely used in local links, since there is no proxy). In practice, HEAD is not even used, as the browser now relies on the server to send a 304 Not modified reply. - The server is single-threaded and serves only one client at a time
* This ensures by design that there can be no race condition.
* The server is typically used by only one client at a time anyway.
* This reduces code complexity and timing issues
* Raw performance and throughput are not critical, since the client and server are usually located next to each other and the server is minimalist, reducing processing and transfer overhead.
The single-socket approach seems to create its own set of troubles with browsers that insist on sending an avalanche of requests no matter what.
A HTTaP server typically provides two separate domains:
- a static files server (a very basic HTTP server)
- a dynamic sever, like an embedded CGI inside the server program.
The URL defines which domain is accessed with a very simple method : static files use standard URLs while dynamic ones start with the "?" character.
The question mark is a common indicator and good heuristic for dynamic contents and would not be messed with by eventual proxies.
- When the requested URI starts with "/?" then the dynamic mode is selected and an embedded program parses the URI.
- Otherwise, this is a standard file, with a direct mapping to the file system (often a sub-directory). There is no support of automatic index.html generation or "open directories".
No access control is provided for the static files, which usuallly contain the HTML/JS web application and all the required supporting files. Access rights must be correctly set on the filesystem by the developer to prevent 403 errors or unwanted access to unrelated files.
Lately, Facebook has added a nasty "fbclid" suffix to outgoing links and this breaks them when they refer to HTTaP resources. Some mitigations on the HTTaP side are possible but they are not considered critical because who would post a HTTaP link on Facebook ?
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.