|
| 1 | +--- |
| 2 | +state: Draft |
| 3 | +start-date: 2024-07-07 |
| 4 | +author: Rodrigo Arias Mallo <[email protected]> |
| 5 | +--- |
| 6 | + |
| 7 | +# Dillo RFC 002 - Rule based mechanism |
| 8 | + |
| 9 | +In order to modify some aspects of the web, we should have a mechanism to extend |
| 10 | +the capabilities of Dillo. |
| 11 | + |
| 12 | +The shortcoming of the current plugin design is that they can only operate on |
| 13 | +protocols. |
| 14 | + |
| 15 | +## Rule language |
| 16 | + |
| 17 | +Using a simple rule language we can build a set of rules that can be quickly |
| 18 | +evaluated in runtime. These rules have the capability to run arbitrary commands |
| 19 | +that the user specifies, which are capable of manipulating the traffic. |
| 20 | + |
| 21 | +They can also operate in such a way that they behave as endpoints, so they can |
| 22 | +implement protocols on their own. |
| 23 | + |
| 24 | +## Design |
| 25 | + |
| 26 | +Dillo currently builds a chain of modules that performs some processing on the |
| 27 | +incoming and outgoing data: |
| 28 | + |
| 29 | + |
| 30 | + (0) +--------+(1) +-------+(2) +------+(3) +-------+ |
| 31 | + ---->| TLS IO |--->| IO |--->| HTTP |--->| CACHE |-... |
| 32 | + Net +--------+ +-------+ +------+ +-------+ |
| 33 | + src/tls.c src/IO.c src/http.c src/capi.c |
| 34 | + |
| 35 | +The user should be able to decide at which stage the rules are hooked. For |
| 36 | +example, at (0) we TLS traffic is still encrypted, so there is only a limited |
| 37 | +actions that can be done there. |
| 38 | + |
| 39 | +At (1,2) we see the HTTP traffic, but it is still compressed (if any). At (3) we |
| 40 | +see it uncompressed, and is the last step before being cached. |
| 41 | + |
| 42 | +Here is an example where we introduce a new module "SED" that sees the incoming |
| 43 | +uncompressed HTTP traffic and can perform modifications: |
| 44 | + |
| 45 | + Net +--------+ +-------+ +------+ +=====+ +-------+ |
| 46 | + ---->| TLS IO |--->| IO |--->| HTTP |---># SED #--->| CACHE |-... |
| 47 | + +--------+ +-------+ +------+ +=====+ +-------+ |
| 48 | + src/tls.c src/IO.c src/http.c | src/capi.c |
| 49 | + | |
| 50 | + +---------+ |
| 51 | + | rulesrc | |
| 52 | + | ... | |
| 53 | + +---------+ |
| 54 | + |
| 55 | +## Feature creep |
| 56 | + |
| 57 | +This design introduces more complexity in the Dillo code base. However, trying |
| 58 | +to manage this feature outside Dillo doesn't seem to be possible, as we need to |
| 59 | +be able to reroute traffic on the different layers. |
| 60 | + |
| 61 | +On the other hand, we can design the rule language in such a way that we only |
| 62 | +allow operations that are quick to evaluate in runtime to reduce the overhead. |
| 63 | + |
| 64 | +## Goals |
| 65 | + |
| 66 | +This feature should be able to implement the following: |
| 67 | + |
| 68 | +- Rewrite HTML pages to correct bugs or introduce new content such as meta |
| 69 | + information in the `<head>` that is rewritten as visible HTML elements. An |
| 70 | + example of such elements are RSS feeds. |
| 71 | + |
| 72 | +- Patch CSS per page. As we can hook the rules to match different properties, we |
| 73 | + can use them to inject new CSS rules or patch the given ones to the user |
| 74 | + liking. This allows fixing broken rules or use fallback features while we add |
| 75 | + support for new CSS features. |
| 76 | + |
| 77 | +- Handle HTTP error status codes like 404 or 500 and redirect them to the web |
| 78 | + archive. |
| 79 | + |
| 80 | +- Redirect JS-only pages to alternatives that can be rendered in Dillo, |
| 81 | + similarly as the [libredirect plugin](https://libredirect.github.io/). |
0 commit comments