Editorial standards

Every page on this site is written to the standards below. They exist because technical reference content fails in specific, predictable ways, and each rule here blocks one of them.

Sourcing#

Primary sources only. Claims are checked against the specification, the official documentation for the version in question, or published source code. The sources a page relied on are listed at the foot of that page with links.

Acceptable sources:

• IETF RFCs and Internet-Drafts, W3C specifications
• Official vendor documentation, versioned where the vendor versions it
• Published source code and official release notes or changelogs
• CVE records and vendor security advisories

Not used as sources: blog posts, forum answers, aggregator articles, or any content whose own sourcing cannot be checked. Those are frequently where an error enters a subject and then propagates. Where a widely repeated claim turns out to be unsupported, the page says so.

Version qualification#

Proxy behaviour changes between releases, and an unqualified claim is a future error. Anything version dependent is stated with the version: "nginx 1.25 and later", "curl 7.86.0 added CIDR support in NO_PROXY", "Traefik v3 changed the matcher syntax". Where a behaviour cannot be pinned to a version with confidence, the page states the uncertainty rather than picking a number.

What may not be published#

• No invented data. No fabricated benchmarks, survey results, percentages, market sizes or quotes. Documented default values are facts and are used freely, clearly labelled as defaults. Numbers that would require measurement we have not done do not appear.
• No filler. No padding paragraphs, no restating the title, no closing summary that repeats the article. If a section does not carry information, it is cut.
• No commodity rewriting. A page that only restates the vendor documentation adds nothing and is not published. Every page must contribute at least one of: a comparison across implementations, a decision rule, an interaction between documented behaviours that is not obvious, or a failure walkthrough from symptom to root cause.
• No vendor ranking for its own sake. Comparisons state what differs and when each option is the right one. They do not declare an overall winner, because the answer depends on constraints the page cannot know.
• No attack recipes. Security pages explain vulnerability classes, detection in your own systems, and remediation. They do not provide step-by-step exploitation of systems the reader does not operate.

Configuration examples#

Examples are written to be correct and minimal, not copy-paste production configuration. They omit the parts specific to your environment on purpose. Every page carrying configuration also carries the caveat that you should check it against the documentation for your exact version before deploying. Where an example is deliberately insecure to illustrate a vulnerability, it is marked as such in the text immediately around it.

Review and updates#

Each page carries an Updated date in its header. That date changes when the content changes, not on a schedule, so a date that has not moved means the page has not needed to.

Pages are re-checked when any of the following happens:

• a major release of software the page covers changes documented behaviour
• an RFC the page relies on is updated or obsoleted
• a reader reports an error or a behaviour we have described imprecisely
• a claim on the page turns out to be unverifiable on re-reading

Corrections#

Errors are fixed in place and logged. Substantive corrections, meaning anything that changes the practical advice or a factual claim, are recorded on the corrections page with the date, the page, what was wrong, and what it now says. Typographic and formatting fixes are not logged.

If you find an error, please tell us. Include the page, the specific claim, and the source or the version that contradicts it. Reports that cite a primary source are actioned fastest, and they are the most useful thing a reader can send.

Tools#

The interactive tools run entirely in the reader's browser. They send no data anywhere and store nothing. Each tool page states the rule the tool implements so the output can be checked rather than taken on trust, and where a tool models behaviour that is not formally specified, such as no_proxy matching, it says explicitly that it is a model of documented and source-derived behaviour and that readers should verify against their exact version.

Advertising and independence#

The site may display advertising. Advertising is never allowed to determine which topics are covered, which products are recommended, or how a product is assessed. There are no sponsored pages, no paid placements in comparisons and no vendor review of content before publication.