Close
0%
0%

HTTaP

Test Access Port over HTTP

Similar projects worth following
HTTaP is a sub-protocol of HTTP1.1 designed to access hardware resources (and more) with a browser-friendly interface. It's a good bet for your IoT project when Apache+CGI don't fit.

It is initially designed to provide a connexion (over a trusted link) to a device (either hardware or software, real, emulated or virtual), on the same computer, or next to it, or on the other side of the planet.

Contrary to other ad hoc protocols or WebSockets, HTTaP can work directly with a HTML/JavaScript page, using only plain GET and POST messages (unlike other lower-level protocols that require system programming). This enables rich and portable interfaces that work on most browser-enabled devices.

HTTaP is designed for use in a lab, in a controlled environment with no outside connexion. Safety, scheduling, encryption and authentication are not part of this protocol. Tunelling over OpenSSL (instead of raw TCP) might solve this.

HTTaP was first published in the french GNU/Linux Magazine n° 173 (july 2014) "HTTaP : Un protocole de contrôle basé sur HTTP" as a simpler alternative to WebSockets.

The project #micro HTTP server in C is designed to implement this protocol.

This project documents the protocol itself, its definitions and evolutions.

.


Logs:
1. Overview
2. Compression
3. Loopback server
4. Vocabulary

.

  • Vocabulary

    Yann Guidon / YGDES2 days ago 0 comments

    This page contains a draft for a uniform/universal URI layout and "vocabulary" that all applications/clients can use.

    HTTaP defines two "domains" :

    • The static domain contains files that do not change. They usually contain all the HTML/JS interface and all the support files. They are cacheable.
    • The dynamic domain is introduced with a « URI with query component(s) », starting with "/?", to prevent them from being stored in cache.

    The dynamic domain is split further:

    • lowercase names are usually reserved for standard HTTaP features (such as listings or loopback)
    • uppercase names describe application-specific resources, signals, like memory, registes, sensors...

    Signal hierarchy uses the object notation (with a dot) to represent hierarchy. As a rule of thumb, if it uses a copy of the circuit or an instance of the code, it will be dot-represented. They will be treated similarly by the handler of the server, for example memory spaces...

    URI comments GET POST
    /somepath/somefile.name Static file to serve. *
    /? Root of HTTaP, serve a JSON-formatted
    list of available of valid dynamic resources names
    *
    /?loopback Loopback for JS save/restore (optional)
    *
    /?list Return the list of the signals and their hierarchy
    *
    /?changes same as /?list but only include signals that have changed
    *
    /?REG read the value of all the registers
    *
    /?REG/R1 read the value of register R1
    *
    /?REG/R1,R2 read the values of registers R1 and R2 (optional?)
    *
    /?MEM Dump the contents of the memory *
    /?MEM/123-456 Dump the contents of the memory from locations 123 to 456 *
    /?IO.SPI.1/ Read the full status of the first SPI port
    *

    I'm not sure about the representation of ranges but they are pretty useful to reduce the bandwidth and CPU load.

  • Loopback server

    Yann Guidon / YGDES2 days ago 0 comments

    HTTaP is meant to help integrate #YGWM with a web-based system, and there is more to it than serving files or sending commands to TCP widgets.

    Any editor needs to read and write files from the local disk/storage and the chosen language/framework (HTML/JS) does not allow that. The web browser prevents scripts from doing it, for obvious security reasons !

    Yet there is a solution. Or more precisely, it's a hack ! I have described it in an article in French:

    "Accéder aux fichiers en JavaScript (ou le Cross-Site Scripting utile)" in GLMF#105 pp.42-54

    This describes a dirty trick, using a PHP script along with a specially crafted HTML/JS page :

    • To read a local file into the JS framework, tell the browser that you want to upload said file to the server. The JS part can't access at all the file contents but the server will reply with a JS-formatted string that is the exact copy of the file. Bazinga !
    • To write a file to the local file system, the JS script will send the properly formatted data as a POST form. The server then transcode and reply with these data advertised as a binary blob of unknown type, which the server will understand as a file to save. Bingo !

    Note : these manipulations usually require user interaction and are not inherently more unsafe than usual methods.

    The PHP script was a pain to write and I'm glad to have a totally controlled environment (the HTTaP server) where I can process the data without layers of gotchas and poisonous sugaring...

    The JS framework has evolved too and "binary blobs" now solve many of the encoding problems I have !

    The "Loopback" feature should be a standard, user-configurable, option in the HTTaP protocol, with its own access key.

  • Compression

    Yann Guidon / YGDES2 days ago 0 comments

    HTTaP should not be used in public-facing networks, where bandwidth is a concern (latency often is more important). Compression is not a priority but it IS possible to implement it.

    The inherent cost is that the server needs to parse the request headers and find the line that declares that compressed files are allowed. It's possible but this uselessly increases the coding effort...

  • Overview

    Yann Guidon / YGDES03/21/2017 at 21:42 0 comments

    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 server side, which uses JavaScript (or other powerful dynamic languages) 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 airgaped networks.
    • Another source of complexity comes from the HTTP "vocabulary" : the only supported methods are GET, PUT and HEAD.
      * GET reads resources (files or dynamic variables) like any usual request.
      * PUT 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).
    • The server is single-threaded
      * This ensures by design that there can be no race condition.
      * The server is typically used by only one client at a time.
      * 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.

    A HTTaP server typically contains two separate domains:

    1. a static files server (a basic HTTP server)
    2. 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.

    1. When the requested URI starts with "/?" then the dynamic mode is selected and an embedded program parses the URI.
    2. 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.

View all 4 project logs

Enjoy this project?

Share      

Discussions

Does this project spark your interest?

Become a member to follow this project and never miss any updates