$ show httpwg/http-extensions
Strictly speaking, this is not a software application; it is the IETF HTTP Working Group's standards-development workspace. The executable surface is minimal: a Makefile built on martinthomson/i-d-template, GitHub Actions workflows for building and publishing drafts, a requirements.txt that pulls in rfc-http-validate for HTTP message linting, an archived proof-of-concept Python parser, and sf.json structured-fields test vectors. The dominant content is Markdown/XML Internet-Drafts for HTTP extensions (cookies, resumable uploads, message signatures, cache groups, no-vary-search, compression dictionaries, optimistic upgrade, and similar protocol work), plus an archive of superseded drafts and a set of shepherd writeups. Forced into the application/data_research dichotomy, it belongs on the application side because it is a versioned, CI-driven engineering workspace with semantic tag-based releases, not a data analysis pipeline. In production, the repository's behavior is: editors revise draft sources, GitHub Actions builds editor copies to gh-pages, generated XML is linted with rfc-http-validate, new versions are published on annotated tags, and template files are periodically regenerated. The primary data flows are IETF document flows: source draft -> generated HTML/XML/TXT -> published RFC or archived draft. The repo relies almost entirely on the external i-d-template toolchain plus small helpers for linting and ASCII-art drawing. Most files under archive/ are intentional historical records rather than stale code, and the writeups/ directory preserves RFC 4858-style shepherd evidence for completed or in-progress documents. Maintenance is genuinely active: recent commits, issue labels per draft, automated publishing, and multiple in-flight specifications at different stages of the IETF process. Technical drift is low because the repository's dependency footprint is deliberately tiny and the active drafts track current HTTPbis discussions. The many old drafts do not represent code rot; they are archived standards history. The main caveat for any consumer is that this repository cannot be treated as a library or framework: it is a source of protocol definitions, conformance fixtures, and process templates, not runtime software.
The LLM identified 3 files worth highlighting for reuse:
Conformance corpus for HTTP Structured Fields (RFC 9651-style Items, Lists, and Dictionaries). It provides named test cases such as variant-key, signature, content-digest, upload-offset, and x-* examples with variant and signature metadata. Any structured-fields parser or serializer implementation can consume this JSON as a dependency-free, cross-language test fixture, making it a genuinely reusable validation artifact.
Self-contained proof-of-concept Python parser for HTTP header structure, exposing CSval/Cshdr classes and demonstrating incremental tokenization of RFC 7230 tokens, optional whitespace, and base64 values. It includes a built-in corpus derived from RFC 7230/7231/7234 headers. Although archived and superseded by mature structured-fields libraries, the file remains readable as a standalone reference for porting an incremental HTTP header parser or for teaching parser design.
Reusable RFC 4858-style shepherd writeup questionnaire used by the HTTP Working Group to record implementation/deployment evidence, consensus, IPR, and AD review status before a draft is published. It is a self-contained process template that an IETF document shepherd for any working group could adapt with minimal changes to shepherd a draft through publication.