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 is initially designed to provide (trusted) connexion to a device (either hardware or software), on the same computer, or next to it, or on the other side of the planet.
The device can be real, emulated or virtual as long as the same set of messages are recognised.

Contrary to other ad hoc protocols, HTTaP can work directly with a HTML/JavaScript page, using only plain GET and PUT 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, encryption and authentication are not part of this protocol, which must not be used in other situations. Therefore it can be a basis for "IoT" devices but it is not a definitive solution.


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

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


  • Overview

    Yann Guidon / YGDES4 days ago 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
    • 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 HTTaP's use cases. 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.
    • 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



    A HTTaP server typically contains two separate domains:

    1. a static files server (a basic HTTP server)
    2. a dynamic sever

    The URL defines which domain is accessed with a very simple method : static files use standard URLs while dynamic ones start with the "?" character.

View project log

Enjoy this project?



Does this project spark your interest?

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