Summary

  • AIRRS’s live JavaScript appends the literal query key amp;profile=afrinic when asking RIPEstat for a result-page structure. In a JavaScript string, that is not an HTML-encoded spelling of profile; it is a different parameter name.
  • On 11 September 2026, default and literal-amp requests returned the same normalized seven-tab structure for an ASN, prefix, domain and country. The correctly named profile=afrinic request returned HTTP 500 for all four.
  • This does not show that the widgets’ underlying data is wrong or unavailable. It shows that a populated dashboard is not evidence that the intended profile was selected.
  • The useful repair is two-sided: make the named profile healthy, make AIRRS send its real name, and expose a small receipt showing the requested profile, selected profile, structure hash, status and fallback.

A dashboard answers before the configuration question is asked

The easiest software checks are often the least informative. Open a page. Enter a resource. See whether charts appear. If they do, declare the service alive. That sequence is attractive because it converts a complicated dependency into a visible yes or no. It is also how a fallback becomes indistinguishable from the intended product.

AIRRS, the African Internet Registry and Routing Statistics portal, is not modest about the job it wants to perform. Its public explanation calls it a collaboration between AFRINIC and RIPE NCC. It says it presents data supplied through RIPEstat in a user-friendly form, with the aspiration of giving regulators, network operators, policy makers and researchers up-to-date information about an Internet resource or a country. AFRINIC’s launch notice places WHOIS, RIPE RIS, RIPE Atlas and several external datasets behind that interface.

The portal advertises four recognisable doors: ASN information, prefix information, domain lookup and a country report.

That framing matters. AIRRS is not merely a decorative link to another site. It is a selection and assembly surface. A reader supplies a resource; AIRRS requests a page structure; the structure determines which RIPEstat widgets appear and how they are grouped. The interface can therefore succeed at rendering while failing at a more precise task: demonstrating that the AFRINIC-specific configuration was the one that shaped the result.

The evidence sits in one small string.

The semicolon that stays a semicolon

The current result-page application identifies itself as an “AFRINIC RIPEstat Template” dated February 2020. Its response headers say the JavaScript was last modified on 11 March 2020. When a user submits a resource, the script builds a URL for RIPEstat’s results-page-structure endpoint. It starts with the resource and then appends:

&profile=afrinic

In HTML text, & is the entity used to display an ampersand. But this line is not HTML text waiting to be decoded by an HTML parser. It is a JavaScript string used as a URL. The first character is already a real ampersand. What follows it is the literal key amp;profile, followed by the value afrinic. The request does not contain a parameter named profile.

This is the sort of defect that survives a visual smoke test. Unknown query keys are often ignored. If the endpoint has a default response, the caller still receives valid JSON. AIRRS can then build tabs, preload widgets and present a coherent page. Nothing in the mere presence of those widgets says why that particular structure was chosen.

The distinction can sound pedantic until it is measured. So the measurement used the four resource shapes AIRRS itself puts in front of readers: AS327800, 196.192.48.0/20, afrinic.net and ZA. For each resource, three requests were preserved. The first had no profile parameter. The second used the literal key emitted by AIRRS, amp;profile=afrinic. The third used the correctly named profile=afrinic.

The resulting twelve-request matrix is unusually clean.

Four resources, the same split

For AS327800, the default request returned HTTP 200, an API status of ok and seven tabs. The literal-amp request did the same. After volatile envelope fields were excluded, the normalized data objects had exactly the same SHA-256 hash. The correctly named AFRINIC profile returned HTTP 500, status: error, status_code: 500, an empty data object and no tabs.

The prefix 196.192.48.0/20 repeated the pattern. Default: 200 and seven tabs. Literal amp;profile: 200 and the same normalized structure. Correct profile: 500 and zero tabs.

The domain afrinic.net repeated it again. So did the country code ZA. Across four different input shapes, there were four successful defaults, four successful literal-amp requests whose normalized structures matched their defaults, and four failures for the correctly named profile.

All twelve responses identified the RIPEstat build as v0.11.15-2026.09.09 and the pipeline as 1415073. Each preserved response also carries its own query identifier and timestamp. This is not a recollection of what the screen seemed to do. It is a bounded observation of what the endpoint returned on 11 September 2026.

One response field deserves care. The failing calls include data_call_status: supported. RIPEstat’s documentation presents status, status_code and data_call_status as separate parts of the response envelope. “Supported” is not a magic word that cancels HTTP 500 or status: error. It indicates that the data call belongs to a supported class; it does not turn an unsuccessful execution into a successful one.

The matrix supports a narrow conclusion. In these four canaries, RIPEstat treated the AIRRS-shaped request like the default request. Direct selection of the named AFRINIC profile failed. It does not reveal the server-side cause of that failure. It does not prove that the profile failed yesterday, that it will fail tomorrow, or that it never worked in 2020. It does not show that all resources behave identically. Four canaries are enough to expose a configuration distinction, not enough to write a universal history.

What seven tabs prove—and what they do not

The default response is not empty. That is precisely why the problem is easy to miss. A seven-tab page may contain useful routing, registry and measurement views. Some may be highly relevant to African operators. AIRRS’s dependence on RIPEstat means the underlying widgets can make their own data calls after the page structure has been selected. Nothing in the observed profile behavior establishes that WHOIS, RIS, Atlas or another dataset is false, corrupt or offline.

What the page cannot currently demonstrate is the provenance of its assembly. Did RIPEstat choose a profile named afrinic? Did it choose the default? Did it fall back after a profile error? Was the returned structure cached? Did the layout change between API builds? The visible result does not answer those questions, and the client’s literal request key answers one of them in an unwelcome way: it did not ask under the name profile.

For a casual visitor, that might look like a minor implementation detail. For the audiences named by AIRRS, it is part of the evidence chain. A regulator comparing country conditions, an operator checking an ASN, a researcher documenting a prefix, or a policy maker citing a chart may reasonably assume that an AFRINIC-branded interface applies an AFRINIC-specific choice. The assumption may be harmless if default and named profiles are intentionally identical. It may matter if profiles select different widgets, ordering, explanatory context or defaults. The current surface supplies no receipt either way.

The point is not that regionalisation guarantees better truth. A profile is a presentation contract, not a certification of the data beneath it. The point is simpler: if a product says it requests a named presentation, the request and response should make that selection auditable. Otherwise branding performs work that configuration evidence does not.

The age gap is evidence, not a verdict

The captured AIRRS client is dated 2020. The RIPEstat responses report a build from 9 September 2026. Six years between a client timestamp and a service build creates an obvious compatibility question, but it does not answer it.

One cannot infer from these dates that RIPE NCC removed a profile, that AFRINIC failed to maintain a dependency, that a library encoded the string, or that a particular deployment introduced the 500. The string may have been present from the beginning or added later without changing the file’s effective timestamp. The named profile may once have returned a structure or may have been intended for an environment no longer visible. The source set does not supply a change log for that relationship.

Nor does the observation allocate fault. AFRINIC controls the public AIRRS client and can correct what it sends or explain its fallback. RIPE NCC controls RIPEstat’s named-profile resolution and response. Either side can add diagnostics. A complete repair may involve both. Treating the matter as a blame contest would replace an observable interface problem with a story the evidence cannot sustain.

The useful lesson from the age gap is operational. A long-lived public client that consumes a frequently rebuilt service needs a compatibility canary at the boundary between them. “The home page loads” is not such a canary. “The same resource, selected under the intended named profile, produces the expected structure and declares the profile actually used” is.

A selection receipt is smaller than a redesign

AIRRS does not need to expose private telemetry or a user’s search history to make this boundary visible. A compact profile-selection receipt could accompany a result page or a public diagnostic endpoint.

It would record the resource shape and the canonical resource, the exact outgoing parameter name, the requested profile and the profile RIPEstat says it selected. If the default was used, the receipt would say default rather than allowing absence to masquerade as AFRINIC selection. It would include a page-structure version or normalized hash, the ordered tab or widget identifiers, the RIPEstat build and query ID, the response timestamp, and the three relevant status fields.

The receipt would also state the fallback rule. If a named profile is unavailable, should AIRRS stop with a clear message? Should it render the default with a visible label? Should it serve the last known good regional structure, with its age? Any of these can be defensible in the right context. The indefensible option is an undocumented transition in which a working page silently stands in for a verified configuration.

Finally, the receipt would publish the last successful canary across the four advertised shapes. That does not require continuous testing of every possible resource. An ASN, prefix, domain and country are enough to catch a broad class of selection and schema regressions. The canaries should record structure hashes, not merely HTTP codes, because a 200 response can carry a materially different layout.

This receipt is a proposed control, not an existing AFRINIC or RIPE NCC obligation. Its value is that it separates three states that the current user experience collapses: the client asked correctly; the named profile resolved successfully; the returned structure was the one expected. Repairing a spelling addresses the first state. Restoring or redefining the named profile addresses the second. Testing hashes and tab identities addresses the third.

Sources