Roadmap

[alganet]

Phase 1: Exploration

• Cover as much of current HTTP-correctedness and best practices as possible.
• Not much care about granularity of rule classes.
• Find out which code must be reused through the extraction of helpers.

Phase 2: Solidify Architecture

• Figure out the right granularity (one rule per header? one rule per type of violation?)
• Figure out defaults (what should warn, what should error out, etc)
• Can we make the linting library a crate separate from the proxy layer?
• Should we make an abstract transaction sink?

Phase X: Release

• ???

[alganet]

We are currently in Phase 1.

[alganet]

I am almost running out of ideas for new linting rules, having covered a lot of scenarios. There is a lot of room for improving existing rules though, particularly by adding features to the core engine (such as persisting more than one request per client+request_target on the state store).

This means we're almost done with Phase 1, and there will probably be some kind of Phase 1.5 where I'll experiment with trade-offs regarding making the engine more capable and keeping simplicity.

[alganet]

I am now officially out of ideas for new rules. There is a category of rules regarding connection specifics that is under-explored, but it would most likely be beyond what the proxy crate we use is able to expose.

It's likely that we stick to being more close to applications to HTTP implementations, so these connection rules don't matter that much. They'd be a nice to have in the future, but they're not essential.

The recent introduction of queries is a point to reconsider. It changes how each rule could be implemented, and could simplify things. We probably need a pass in each rule for re-alignment with the architecture.

This project is probably going into a 1-week hiatus while I experiment with it now that most rules are implemented. They're (intentionally) sloppy, and producing duplicated violation warnings and all sorts of rough edges. I'll need data on those to decide the next steps.

[alganet]

NVM, it seems I have found some new introspectable HTTP aspects that rules can be written for. #263 is a work on that front. New rules coming soon!

[alganet]

We've come a long way, with a major multi-crate refactoring, several internal redesigns and other codebase improvements.

What's left for the roadmap now is just rule alignment. We need to audit every single existing rule in real-world-ish scenarios and adjust everything. After that, a final wrap-up if nothing critical is found.

The rule realignment is necessary. These rules as they are will likely misfire (report multiple similar violations for the same issue) or have inconsistent names and messages. That's precisely what we need to work on next.