Kiel plusendilo traktas memfaritan API-kapon

API povas porti sian version en memfarita petkampo kiel API-Version. Ordinara plusenda prokura servilo ne devus forĵeti tiun kampon nur ĉar la nomo estas nekonata. HTTP postulas plusendadon de nerekonitaj kampoj, krom se difinita escepto aŭ agordita politiko validas.

La kampo Connection estas unu tia escepto. Komparu ĉi tiujn ilustrajn petojn:

API-Version: 2026-10
Connection: keep-alive

Ĉi tie la API-kampo ne estis markita kiel loka por ĉi tiu konekto. En la sekva ekzemplo la sendanto eksplicite ŝanĝas ĝian amplekson:

API-Version: 2026-10
Connection: API-Version

Plusenda prokura servilo forigas kampojn nomitajn de Connection antaŭ ol plusendi, kaj forigas aŭ anstataŭigas la konektospecifajn instrukciojn mem. Aplikaĵa kapo celita al la origino do ne devus aperi en tiu ĵetona listo.

Trovu la punkton, kie la kampo ŝanĝiĝas

Komparu la peton konstruitan de la kliento, la kampojn ricevitajn kaj plusenditajn de la prokura servilo, kaj tion, kion ricevis la origino. Kliento povas preterlasi kapon antaŭ ol la prokura servilo vidas ĝin; agordita filtrilo povas intence forigi ĝin; servilo povas malakcepti peton pro transpaso de kapa limo.

Ne konkludu silentan forigon nur el kapa granda sojlo raportita en malnova starigo. Limoj kaj malakcepta konduto apartenas al la efektivaj komponantoj kaj agordo. Konservu la HTTP-respondon kaj la koncernajn protokolojn kune kun la observado.

Ĉe HTTPS de fino al fino ene de ordinara CONNECT-tunelo, la prokura servilo ne povas legi kaj selekte forigi la internan API-kampon. Kapa inspektado tiam apartenas al la TLS-finpunktoj aŭ al eksplicite fidinda inspekta peranto.