Skip to content

feat(gateway): add HTTP head validation and bounded JSON primitives - #177

Closed
freeqaz-openai wants to merge 12 commits into
feat/github-gateway-contractsfrom
feat/github-gateway-runtime
Closed

freeqaz-openai wants to merge 12 commits into
feat/github-gateway-contractsfrom
feat/github-gateway-runtime

Conversation

@freeqaz-openai

@freeqaz-openai freeqaz-openai commented Sep 15, 2026 •

Copy link
Copy Markdown
Collaborator

Summary

Add native HTTP request-head inspection and bounded canonical JSON snapshots for the credential gateway.

The inspector accepts the six supported GitHub metadata, fetch/push and PR routes, rejects ambiguous targets, headers and framing, and returns frozen untrusted route data without retaining Authorization text. The consumer must configure Node's strict parser, wire-byte cap and complete raw-header visibility, then authenticate and admit the request before body continuation.

The JSON component copies supported own data into an immutable snapshot, sorts keys, normalizes negative zero and enforces byte, depth and node bounds without invoking caller serialization hooks. Parsing or canonicalization supplies no authority.

The supplier constructor fixture belongs to the controller alongside #174's concrete GitHub token provider. Its original assertions and the OCC State, inventory and lifetime checks remain unchanged: 24 supplier negative assertions in total. Required typechecking continues to select the HTTP and both supplier fixture projects.

Current supplier refresh and validation

This update receives #174 at 65f7d3202ab86ae3efa7ea296c9cbb14eabed6e6, including main's Agent stop and Go CLI changes. HTTP/JSON source and supplier compiler fixtures are unchanged; the complete migration tree matches the accepted supplier.

  • HTTP/JSON component suites: 11 passed, 0 failed, 0 skipped.
  • All four TypeScript projects passed: the root build, OCC gateway fixtures, HTTP primitives and controller token-provider fixtures.
  • Generated OpenAPI/reference checks, workspace boundaries, CI test selection, full formatting, documentation length and diff whitespace checks passed. The authored documentation build validated 119 pages and 1,434 links.

These checks resolve the local typecheck and generated-API gaps recorded at 24857c2db4d6ceb8ba9e85f8d178c449749ae0af. That earlier revision also passed 53 inherited provider checks and three documentation/site checks without skips; those suites were not rerun for this refresh. PostgreSQL, live-provider and runtime qualification were not rerun. Required hosted CI must validate this exact revision before merge.

Dependency and scope

Based on #174. Authenticated server construction, durable broker admission, body/EOF handling and upstream dispatch remain separate integration work. #180 and #182 build on this component.

@freeqaz-openai
freeqaz-openai marked this pull request as ready for review September 16, 2026 02:27
@freeqaz-openai
freeqaz-openai requested a review from a team as a code owner September 16, 2026 02:27
@kevinlin-openai

Copy link
Copy Markdown
Collaborator

Please remove the hardcoded GitHub behavior from the credential gateway and express it through provider-neutral primitives, following the same abstraction direction requested for #141.

apps/credential-gateway/src/http/request.ts currently embeds GitHub hosts, route patterns, methods, query restrictions, content types, and operation-specific limits. Those are repository-provider rules and should be supplied by the provider rather than built into the gateway.

One concrete composition would be:

  • The RepoDriver supplies the supported hosts, routes, methods, and valid URL/query parameters for its repository operations, along with the relevant request constraints.
  • During bootstrap, the credential gateway composes with the configured RepoDriver to validate requests for that repository.
  • The gateway owns shared HTTP parsing, framing, and generic validation primitives, and applies the supplied provider rules. The GitHub RepoDriver owns the GitHub-specific definitions.

For example, /repos/o/r?x=1 is a valid HTTP request target. Whether x is supported should be decided by the RepoDriver's declared rules; a GitHub-specific regex in the shared gateway should not make that decision. Unsupported parameters can still be rejected according to those rules.

Please update the tests and docs to demonstrate this composition and distinguish malformed HTTP from valid requests excluded by a provider's supported operations. Adding another repository provider should not require editing the gateway's core route validator.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants