Repository navigation
refactor(application): use the RFC names HTTP/1 and HTTP/2 in HTTP's id()? #2524
Description
The owner asked in session whether HTTP's id() should use the RFC canonical names, by the same reasoning as the ICMPv4 and IGMPv1 rulings in protocol-family-grouping.rst's Canonical Names section.
Today, unchanged since 1.5.1: HTTP.id() is ('HTTP', 'HTTPv1', 'HTTPv2'), HTTPv1.id() is ('HTTP', 'HTTPv1') and HTTPv2.id() is ('HTTP', 'HTTPv2'). The per-message alias already carries the exact version: HTTP/0.9, HTTP/1.0, HTTP/1.1 or HTTP/2.
Decision needed: what names go in the version slots of id()?
HTTP/1andHTTP/2, keeping the family-inclusive shape:('HTTP', 'HTTP/1', 'HTTP/2'),('HTTP', 'HTTP/1')and('HTTP', 'HTTP/2').HTTP/1.1andHTTP/2, the RFC 9112 and RFC 9113 titles.- Keep
HTTPv1andHTTPv2.
Recommendation: 1. RFC 9113 names HTTP/2 exactly that. No RFC is titled HTTP/1, but the v1 class parses 0.9, 1.0 and 1.1, so HTTP/1.1 would misname 1.0 traffic, and the alias already gives the exact version. Either 1 or 2 is breaking: layer == 'HTTPv1' stops matching, because string == checks only id(). The HTTPv1/HTTPv2 registry keys keep selecting through the class. 'HTTP/2' in frame and frame['HTTP/2'] start matching, which brings Protocol selectors in line with ProtoChain's alias match. The doc's Selector Matching examples and Member Shapes table change with it, and the change gets versionchanged:: 1.6.0.
Activity
JarryShaw commentedon Nov 1, 2026
i think it should be
HTTP.id()->(HTTP/1, HTTP/2)HTTPv1.id()->(HTTP/1,)HTTPv2.id()->(HTTP/2,)we've got convention in action from ICMP and IGMP.
JarryShaw commentedon Nov 1, 2026
Owner ruling, paraphrased: HTTP follows the ICMP/IGMP canonical-name convention fully. The members narrow to their RFC names, and the base lists only the members:
HTTP.id()→('HTTP/1', 'HTTP/2'), members only, in the shape ofIP.id()(('IPv4', 'IPv6')).HTTPv1.id()→('HTTP/1',)andHTTPv2.id()→('HTTP/2',), each narrowed to itself.Reconciled against the options above: this takes option 1's names, with the narrow-to-self shape rather than the family-inclusive one. It is breaking, because string
==checks onlyid(), solayer == 'HTTPv1'andlayer == 'HTTP'stop matching. TheHTTP/HTTPv1/HTTPv2registry keys still select through their classes. The change carriesversionchanged:: 1.6.0and updates protocol-family-grouping.rst's Member Shapes, Canonical Names and Selector Matching to match. Dispatched.JarryShaw commentedon Nov 1, 2026
The ruled
id()tuples are done locally (9cc9d5110). Its review says the code is correct, and asks for text fixes: five stale cross-references and a fuller breaking note. The #2529 class renames (httpv1.HTTPv1,httpv2.HTTPv2, with their schema/data classes per Q2) join that fix round. Decision needed: version selectors on a parsed layer. A parsed HTTP/1.1 or HTTP/2 layer is always the baseHTTPclass, andHTTP.id()lists both members, so'HTTP/1' in,'HTTP/2' inandlayer == 'HTTP/2'are all True on either frame. That breaks Selector Matching's rule that each version name selects its own (#2443). Part of it already held on main ('HTTPv2' inan HTTP/1.1 frame), and part is new (the protochain's'HTTP/2'used to be False on HTTP/1.1).alias/versiontell the versions apart, and nothing else changes.HTTPv1/HTTPv2as IGMP does or with an instance-awareid(). That moves the data key fromhttptohttpv1/httpv2, which shipped, so it is breaking.Recommendation: 1. It keeps the shipped
infokey, andaliasalready carries the exact version. The page states the exception.JarryShaw commentedon Nov 1, 2026
Take 2
JarryShaw commentedon Nov 1, 2026
Owner chose 2: a parsed HTTP layer narrows to its own version. A frame is dispatched to
HTTPv1/HTTPv2, as IGMP is, so'HTTP/1' in,'HTTP/2' inandlayer == 'HTTP/2'match only their own version. That restores Selector Matching's rule from #2443, with no HTTP exception.It is breaking: the data key moves from
httptohttpv1/httpv2, matching IGMP'sinfo_nameruling (a). It goes into the running #2524 fix round on the same branch, after that round reports back.