Skip to content

Repeated RequestExtensions can downgrade negotiated extensions #681

Description

@bit-aloo

handle_request_extensions accepts repeated extension negotiation requests and overwrites negotiated_extensions each time. A downstream can therefore negotiate a set of extensions and later send another request containing only a subset.

This allows the connection's negotiated extension state to be silently downgraded during the same session.

Extension negotiation should only be accepted once per connection, or subsequent requests should preserve the already negotiated state.

Loupe relationship and completion boundary

Loupe #9 reports the application-specific path described here. The canonical remediation record is #771, which covers the confirmed shared defect and owns the Loupe closure criteria.

This issue is an implementation sub-issue, not a second canonical closure owner. A PR may complete this application's work and close this implementation issue while #771 remains open for other affected implementations. Do not close Loupe #9 solely because this child issue is closed. The PR must identify the covered call site, fixing change and regression test, and link #771 for the remaining cross-application completion check.

When all confirmed affected implementations satisfy #771's acceptance criteria, the completing PR must explicitly reference the canonical issue and its Loupe closure targets. This paragraph does not broaden this child's application scope.

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions