En QR-kode, der åbner en side i browseren, beviser endnu ikke, at en resolver er robust. For en resolver til denne type GS1-link tæller den komplette HTTP-adfærd: Hvilke identifikatorer accepteres? Hvilket mål er standarden? Leverer tjenesten et maskinlæsbart linkset? Fungerer browseradgang på tværs af andre domæner? Og rapporterer ugyldige eller utilgængelige forespørgsler den rigtige fejl?
Siden 16. januar 2026 foreligger GS1-Conformant Resolver Standard 1.2.0. Den tilhørende offentlige GS1-testpakke regnes nu som stabil; dens kode blev senest opdateret 29. juni 2026. Dermed kan en abstrakt standard omsættes til en konkret accepttest. Dette indlæg viser, hvad der bør kontrolleres før go-live, hvor testpakken har begrænsninger, og hvilken dokumentation der bør indgå i en teknisk godkendelse.
En vellykket scanning er kun begyndelsen
En GS1 Digital Link indeholder en GS1-identifikator i en HTTPS-URI. Resoveren forbinder denne identifikator med en eller flere ressourcer, f.eks. en produktside, en vejledning, et datablad eller en programmeringsgrænseflade. Vores grundindlæg forklarer resolveren til denne type GS1-link med et liveeksempel. Til en produktionsgodkendelse er en vellykket standardredirect dog ikke nok.
Resolverstandarden 1.2.0 kræver blandt andet HTTPS, understøttelse af GET, HEAD og OPTIONS, Cross-Origin Resource Sharing (CORS), et identificerbart standardlink samt et linkset-output. Ved linkType=linkset eller Accept-headeren application/linkset+json må resolveren ikke omdirigere. I stedet skal den returnere de tilgængelige typede links som en selvstændig repræsentation.
Denne adskillelse er vigtig: Den menneskelige browsersti kan fungere, mens maskinadgang, sprog, linktyper eller fejltilfælde er defekte. Netop sådanne afvigelser forbliver usynlige ved en ren scanningstest.
Godkendelsesplanen i syv trin
1. Fastlæg repræsentative test-URI'er
Begynd ikke med ét enkelt mønsterprodukt. Sammensæt en lille, versionsstyret testsamling:
- mindst én gyldig identifikator pr. understøttet GS1-primærnøgle;
- et GTIN-tilfælde uden kvalifikator;
- tilfælde med batch- eller serienummer, hvis denne granularitet understøttes;
- en syntaktisk ugyldig identifikator;
- en gyldig, men ukendt identifikator;
- en kendt identifikator uden den ønskede linktype.
Standarden tillader, at en resolver kun understøtter en delmængde af GS1-primærnøglerne. For hver understøttet primærnøgle skal dens kvalifikatorer og dataattributter dog behandles fuldstændigt. Derfor skal testmængden passe til den faktisk erklærede funktionalitet, ikke til en generel markedsføringspåstand.
2. Kontrollér standardredirect og metoder
Test først det normale kald uden særlige headere. Der forventes et deterministisk standardlink. Derefter følger HEAD og OPTIONS: HEAD må ikke bruge en anden routingslogik end GET, og OPTIONS skal gøre de tilbudte metoder forståelige.
En minimal manuel test ser således ud:
curl -sS -D - -o /dev/null \
"https://id.gs1.org/01/09506000134352"
curl -sS -I \
"https://id.gs1.org/01/09506000134352"
Dokumentér statuskode, Location, cache-headere og antallet af redirects. En redirect-loop, et tilfældigt mål eller en sti, der varierer efter metode, er en fejl i godkendelsen, også selv om en smartphone på et tidspunkt viser en side.
3. Anmod om linkset i stedet for en webside
Den vigtigste maskinkontrol er linksettet:
curl -sS \
-H "Accept: application/linkset+json" \
"https://id.gs1.org/01/09506000134352"
RFC 9264 definerer application/linkset+json som en selvstændig JSON-repræsentation af en mængde typede weblinks. GS1 skærper kontrakten: Outputtet skal validere mod det normative linkset-skema for version 1.2.0. Kontrollér derfor ikke kun, om der returneres JSON, men også medietype, skema, absolutte mål-URI'er, anchor og linkrelationer.
Særligt vanskelige er formelt gyldige, men fagligt forkerte linksets: f.eks. en manual under linktypen for en produktinformationsside eller et serienummerrelateret mål på GTIN-niveauet. Skemavalidering og faglige fixtures hører derfor sammen.
4. Kontrollér resolverbeskrivelsen
En konform resolver stiller en maskinlæsbar beskrivelse til rådighed under /.well-known/gs1resolver. Den angiver blandt andet resolverens rod og de understøttede primærnøgler. Filen skal validere mod GS1-skemaet for resolverbeskrivelsesfiler.
Denne test forhindrer en hyppig inkonsistens: Tjenesten kan mere eller mindre, end dens egen beskrivelse hævder. Medtag derfor både skemavalidering og en sammenligning med virkelige testtilfælde i godkendelsen.
5. Test CORS og content negotiation
CORS er ikke en bekvemmelighedsfunktion. Standarden kræver det, så browserbaserede applikationer kan kontakte resolveren på tværs af domæner. Test mindst én tilladt browser-origin samt preflight-stien. Kontrollér desuden, om Accept: application/linkset+json og linkType=linkset leverer konsistente resultater.
Tilføj en negativ test for en ikke-understøttet medietype. En tjeneste, der altid sender HTML uafhængigt af Accept-headeren, er ganske vist tilgængelig for mennesker, men kan ikke læses pålideligt af maskiner.
6. Dæk sprog, kontekst og granularitet
Standarden ser Accept-Language samt queryparameteren context som midler til at skelne mellem flere passende links. Ikke alle resolvere skal tilbyde alle varianter. Hvis sprog eller kontekst understøttes, skal udvælgelsesreglerne dog være reproducerbare.
Test derfor et tilgængeligt sprog, et ikke-tilgængeligt sprog og en defineret fallback-rækkefølge. For GTIN, batch og serienummer gælder samme princip: En finere identifikator må tage relevante links på højere niveauer i betragtning uden at udviske den faglige tilknytning. Fastlæg den forventede linkmængde som fixture; rene snapshot-tests af rækkefølgen er for skrøbelige.
7. Skeln semantisk mellem fejl
Fejlkoder er en del af kontrakten. Resolverstandarden foreskriver en meddelelse med HTTP 400 for syntaktisk ugyldige GS1-identifikatorer. Når der anmodes om en konkret, utilgængelig linktype, er en redirect til standardmålet netop ikke det rigtige svar. Sådanne tilfælde skal adskilles fra en ukendt, men syntaktisk gyldig identifikator.
Kontrollér også, at fejlbeskeder ikke afslører interne detaljer, tokens eller stacktraces, og at GET, HEAD og browserbaserede forespørgsler bevarer samme semantik. Et pænt HTML-fejldokument kan ikke opveje en forkert statuskode.
Brug GS1-testpakken rigtigt
Den offentlige testpakke modtager en Digital-Link-URI og kontrollerer adfærden mod Resolver 1.2.0. Den egner sig godt som et uafhængigt smoke- og konformitetstjek. Gem testdatoen, den testede URI, standardversionen, resultatet og eventuelle reproducerbare fejltilfælde som en del af godkendelsen.
Pakken erstatter dog ikke din egen regressionstest. GS1 gør udtrykkeligt opmærksom på, at den i øjeblikket ikke kontrollerer komprimering. Hvis din resolver behandler EPC-binærstrenge eller andre komprimerede former, skal du bruge separate testvektorer til dette. Den offentlige pakke kender heller ikke dine faglige linktyper eller dine krav til autorisation, lejere eller tilgængelighed.
En robust proces kombinerer derfor tre niveauer:
- den offentlige GS1-pakke som ekstern konformitetskontrol;
- skematests for linkset og resolverbeskrivelse i CI;
- egne end-to-end-tests for virkelige identifikatorer, roller, sprog og fejl.
Hvad skal indgå i godkendelsesdokumentationen?
En godkendelse kan først gentages, når resultatet ikke kun er synligt i browseren, men også dokumenteret. Godkendelsesdokumentationen bør som minimum indeholde standard- og pakkeversion, testtidspunkt, målmiljø, test-URI'er, forventede linktyper, HTTP-resultater, skemavalidering, CORS-kontrol og kendte undtagelser.
Automatisér de stabile dele i CI, men gennemfør en målrettet ekstern kørsel mod den offentlige pakke før hver væsentlige ændring af resolveren. Så bliver "QR-koden åbner sig" til en kontrollerbar påstand om identitet, routing og maskinlæsbare produktoplysninger.
