ristypes.ASPath is now a struct: Sequence holds the path's AS numbers in order; Set holds the members of an AS set of several members that ends the path. Origin() returns the last AS of the sequence, or 0 (none) when the path ends in such a set or is empty.
The prefix and AS handlers take the origin from Origin(); the peering handler uses Sequence only.
The stored and shown AS path still lists the set's members at the end, and the AS handler still records them as seen ASes.
The prefix page and the prefix length pages show origin 0 as no known origin, with no AS link or description; the IP lookup asks no WHOIS lookup for it; README's API section says what it means.
Not visible in the diff: the prefix handler used to skip every announcement with origin 0. It now stores one whose path ends in a set, so a peer that re-announces a prefix with such a path replaces its earlier route. Empty AS paths are unchanged: not stored. AS 0 is never recorded as an AS, so /as/0 still answers 404.
Disclosures:
Deviation from the plan: a one-member set at the end is decoded into Sequence, so the origin and the peerings need no separate case for it.
Judgement call: the prefix page lists and counts the routes with no known origin as one of its origins, as the prefix JSON does under the key 0.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/routewatch/issues/75.
`ristypes.ASPath` is now a struct: `Sequence` holds the path's AS numbers in order; `Set` holds the members of an AS set of several members that ends the path. `Origin()` returns the last AS of the sequence, or 0 (none) when the path ends in such a set or is empty.
- The prefix and AS handlers take the origin from `Origin()`; the peering handler uses `Sequence` only.
- The stored and shown AS path still lists the set's members at the end, and the AS handler still records them as seen ASes.
- The prefix page and the prefix length pages show origin 0 as no known origin, with no AS link or description; the IP lookup asks no WHOIS lookup for it; README's API section says what it means.
Not visible in the diff: the prefix handler used to skip every announcement with origin 0. It now stores one whose path ends in a set, so a peer that re-announces a prefix with such a path replaces its earlier route. Empty AS paths are unchanged: not stored. AS 0 is never recorded as an AS, so `/as/0` still answers 404.
Disclosures:
- Deviation from the plan: a one-member set at the end is decoded into `Sequence`, so the origin and the peerings need no separate case for it.
- Judgement call: the prefix page lists and counts the routes with no known origin as one of its origins, as the prefix JSON does under the key `0`.
Model: opus-5-5
A route whose origin is 0 is shown as AS 0. Before this change the prefix handler never stored a route with origin 0; now every path that ends in a set of several members gives one, and the readers treat 0 as a real AS. handlePrefixDetail in internal/server/handlers.go (template internal/templates/prefix_detail.html) shows "AS0" as the origin AS, linked to /as/0, which answers 404. handlePrefixLength and handlePrefixLength6 (template internal/templates/prefix_length.html) show "AS0 (Internet Assigned Numbers Authority)", the bundled description of the reserved AS 0, so the page says IANA originates the route. handleIPInfo answers "asn": 0, and since AS 0 has no row in the AS table, every lookup of such an address queues a WHOIS lookup of AS 0 whose result is never stored. Acceptable: where a route has origin 0, the pages say it has no known origin, with no AS link or description; the IP lookup queues no WHOIS lookup for 0; the README's API section says what an origin of 0 means; a test covers a page showing such a route.
An announcement with an empty AS path is now stored, with origin 0. Origin() in internal/ristypes/ris.go returns 0 for an empty path, and flushBatch in internal/routewatch/prefixhandler.go now stores every announcement, so an empty-path announcement, which next does not store, becomes a live route with no origin. The issue covers only sets, and under RFC 6811, the reading the issue takes, the origin of an empty path is the BGP speaker's own AS, not none. Acceptable: an announcement with an empty path is handled as on next (not stored), so this change alters only paths that end in a set; storing empty-path routes, with whatever origin, is a separate issue.
Model: opus-5-5
1. A route whose origin is 0 is shown as AS 0. Before this change the prefix handler never stored a route with origin 0; now every path that ends in a set of several members gives one, and the readers treat 0 as a real AS. `handlePrefixDetail` in `internal/server/handlers.go` (template `internal/templates/prefix_detail.html`) shows "AS0" as the origin AS, linked to `/as/0`, which answers 404. `handlePrefixLength` and `handlePrefixLength6` (template `internal/templates/prefix_length.html`) show "AS0 (Internet Assigned Numbers Authority)", the bundled description of the reserved AS 0, so the page says IANA originates the route. `handleIPInfo` answers `"asn": 0`, and since AS 0 has no row in the AS table, every lookup of such an address queues a WHOIS lookup of AS 0 whose result is never stored. Acceptable: where a route has origin 0, the pages say it has no known origin, with no AS link or description; the IP lookup queues no WHOIS lookup for 0; the README's API section says what an origin of 0 means; a test covers a page showing such a route.
2. An announcement with an empty AS path is now stored, with origin 0. `Origin()` in `internal/ristypes/ris.go` returns 0 for an empty path, and `flushBatch` in `internal/routewatch/prefixhandler.go` now stores every announcement, so an empty-path announcement, which `next` does not store, becomes a live route with no origin. The issue covers only sets, and under RFC 6811, the reading the issue takes, the origin of an empty path is the BGP speaker's own AS, not none. Acceptable: an announcement with an empty path is handled as on `next` (not stored), so this change alters only paths that end in a set; storing empty-path routes, with whatever origin, is a separate issue.
Model: opus-5-5
A path that ends in an AS set of several members, such as
[64496, 64497, [64498, 64499]], now has no origin: its route is stored
with origin 0 (none), and no member of the set is in a peering. A set of
one member counts as that AS. An announcement with an empty path is
still not stored.
ASPath keeps such a set apart from the sequence and gives the origin.
The prefix and AS handlers take the origin from it; the peering handler
uses the sequence only. The stored AS path still lists the set's members
at the end.
The prefix and prefix length pages show origin 0 as no known origin, the
IP lookup asks no WHOIS lookup for it, and the README says what it means.
Model: opus-5-5
The prefix page (origin list and route table) and the prefix length pages show origin 0 as "No known origin", with no link or description; GetIPInfoContext no longer marks origin 0 as needing a WHOIS lookup, so the IP lookup queues none and the WHOIS fetcher never gets 0 (its own scan reads only recorded ASes, and AS 0 is never recorded, so /as/0 stays 404); README's API section says what an origin of 0 means. TestPagesSayOriginZeroIsNoKnownOrigin covers both pages, TestGetIPInfoNeedsNoWHOISRefreshForOriginZero the WHOIS check.
An announcement is stored only when its path gives an origin or ends in a set of several members, so an empty path is handled as on next; TestPrefixHandlerDoesNotStoreAnAnnouncementWithAnEmptyPath covers it, and the PR body says so.
Model: opus-5-5
1. The prefix page (origin list and route table) and the prefix length pages show origin 0 as "No known origin", with no link or description; `GetIPInfoContext` no longer marks origin 0 as needing a WHOIS lookup, so the IP lookup queues none and the WHOIS fetcher never gets 0 (its own scan reads only recorded ASes, and AS 0 is never recorded, so `/as/0` stays 404); README's API section says what an origin of 0 means. `TestPagesSayOriginZeroIsNoKnownOrigin` covers both pages, `TestGetIPInfoNeedsNoWHOISRefreshForOriginZero` the WHOIS check.
2. An announcement is stored only when its path gives an origin or ends in a set of several members, so an empty path is handled as on `next`; `TestPrefixHandlerDoesNotStoreAnAnnouncementWithAnEmptyPath` covers it, and the PR body says so.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Fixes #75.
ristypes.ASPathis now a struct:Sequenceholds the path's AS numbers in order;Setholds the members of an AS set of several members that ends the path.Origin()returns the last AS of the sequence, or 0 (none) when the path ends in such a set or is empty.Origin(); the peering handler usesSequenceonly.Not visible in the diff: the prefix handler used to skip every announcement with origin 0. It now stores one whose path ends in a set, so a peer that re-announces a prefix with such a path replaces its earlier route. Empty AS paths are unchanged: not stored. AS 0 is never recorded as an AS, so
/as/0still answers 404.Disclosures:
Sequence, so the origin and the peerings need no separate case for it.0.Model: opus-5-5
A route whose origin is 0 is shown as AS 0. Before this change the prefix handler never stored a route with origin 0; now every path that ends in a set of several members gives one, and the readers treat 0 as a real AS.
handlePrefixDetailininternal/server/handlers.go(templateinternal/templates/prefix_detail.html) shows "AS0" as the origin AS, linked to/as/0, which answers 404.handlePrefixLengthandhandlePrefixLength6(templateinternal/templates/prefix_length.html) show "AS0 (Internet Assigned Numbers Authority)", the bundled description of the reserved AS 0, so the page says IANA originates the route.handleIPInfoanswers"asn": 0, and since AS 0 has no row in the AS table, every lookup of such an address queues a WHOIS lookup of AS 0 whose result is never stored. Acceptable: where a route has origin 0, the pages say it has no known origin, with no AS link or description; the IP lookup queues no WHOIS lookup for 0; the README's API section says what an origin of 0 means; a test covers a page showing such a route.An announcement with an empty AS path is now stored, with origin 0.
Origin()ininternal/ristypes/ris.goreturns 0 for an empty path, andflushBatchininternal/routewatch/prefixhandler.gonow stores every announcement, so an empty-path announcement, whichnextdoes not store, becomes a live route with no origin. The issue covers only sets, and under RFC 6811, the reading the issue takes, the origin of an empty path is the BGP speaker's own AS, not none. Acceptable: an announcement with an empty path is handled as onnext(not stored), so this change alters only paths that end in a set; storing empty-path routes, with whatever origin, is a separate issue.Model: opus-5-5
41ebf1eff6toac338d8f10GetIPInfoContextno longer marks origin 0 as needing a WHOIS lookup, so the IP lookup queues none and the WHOIS fetcher never gets 0 (its own scan reads only recorded ASes, and AS 0 is never recorded, so/as/0stays 404); README's API section says what an origin of 0 means.TestPagesSayOriginZeroIsNoKnownOrigincovers both pages,TestGetIPInfoNeedsNoWHOISRefreshForOriginZerothe WHOIS check.next;TestPrefixHandlerDoesNotStoreAnAnnouncementWithAnEmptyPathcovers it, and the PR body says so.Model: opus-5-5
Review passed.
Model: opus-5-5