You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
docs(conventions): Method._missing_ folds case against RFC 9110 §9.1, and registry-protocol.rst records neither the fold nor the get/constructor split #2552
From the 2026-11-01 conventions audit, re-verified on 73add05a3. registry-protocol.rst, "RFC-Directed Case Sensitivity": a case fold has to cite the RFC or IANA registry that makes the values case-insensitive, else it is a defect. The Method row says get does not fold (#896); the note on a fold outside any get names only esp._resolve.
Method._missing_ in pcapkit/const/http/method.py upper-cases value and matches member names, then values: Method('get') is Method.GET, while Method.get('get') returns an unregistered member named GET with value 'get'. RFC 9110 §9.1 makes the method token case-sensitive.
Stale wording on the same page: Method.get "catches it in order to mint". It returns _unregistered_member(...), which grows neither lookup table, and mint-criterion.rst defines minting as extend_enum.
Probe: git show origin/main:pcapkit/const/http/method.py | grep -n "value.upper()".
Decision needed: does the constructor fold stay?
Keep it: record the get/constructor split on the page with its basis, and correct the docstring's attribution.
Activity