Verifiera rubriker

GÄLLER FÖR: Alla API Management-nivåer

Principen validate-headers validerar svarshuvudena mot API-schemat.

Principuttryck

<validate-headers specified-header-action="ignore | prevent | detect" unspecified-header-action="ignore | prevent | detect" errors-variable-name="variable name">
    <header name="header name" action="ignore | prevent | detect" />
</validate-headers>

Attribut

Element

Åtgärder

Innehållsvalideringsprinciperna innehåller ett eller flera attribut som anger en åtgärd, som API Management tar när en entitet verifieras i en API-begäran eller ett svar mot API-schemat.

• En åtgärd kan anges för element som representeras i API-schemat och, beroende på principen, för element som inte representeras i API-schemat.

• En åtgärd som anges i en princips underordnade element åsidosätter en åtgärd som angetts för dess överordnade element.

Tillgängliga åtgärder:

Förbrukning

• Principavsnitt: utgående, on-error
• Principomfattningar: global, arbetsyta, produkt, API, åtgärd
• Gatewayer: klassisk, v2, förbrukning, lokalt installerad, arbetsyta

Användningsanteckningar

• Den här principen kan bara användas en gång i ett principavsnitt.

Loggar

Information om valideringsfelen under principkörningen loggas till variabeln som anges i context.Variableserrors-variable-name attributet i principens rotelement. När det konfigureras i en prevent åtgärd blockerar ett valideringsfel ytterligare bearbetning av förfrågningar eller svar och sprids även till egenskapen context.LastError .

Om du vill undersöka fel använder du en spårningsprincip för att logga felen från kontextvariabler till Application Insights.

Prestandaöverväganden

Att lägga till en valideringsprincip kan påverka API-dataflödet. Följande allmänna principer gäller:

• Ju större API-schemastorlek desto lägre blir dataflödet.
• Ju större nyttolast i en begäran eller ett svar, desto lägre blir dataflödet.
• Storleken på API-schemat har en större inverkan på prestanda än storleken på nyttolasten.
• Validering mot ett API-schema som är flera megabyte i storlek kan orsaka tidsgränser för begäran eller svar under vissa förhållanden. Effekten är mer uttalad i förbruknings- och utvecklarnivåerna för tjänsten.

Vi rekommenderar att du utför belastningstester med dina förväntade produktionsarbetsbelastningar för att utvärdera effekten av valideringsprinciper på API-dataflödet.

Exempel

<validate-headers specified-header-action="ignore" unspecified-header-action="prevent" errors-variable-name="responseHeadersValidation" />

Valideringsfel

API Management genererar innehållsverifieringsfel i följande format:

{
 "Name": string,
 "Type": string,
 "ValidationRule": string,
 "Details": string,
 "Action": string
}

I följande tabell visas alla möjliga fel i valideringsprinciperna.

• Information: Kan användas för att undersöka fel. Inte tänkt att delas offentligt.
• Offentligt svar: Felet returnerades till klienten. Läcker inte implementeringsinformation.

När en valideringsprincip prevent anger åtgärden och genererar ett fel innehåller svaret från API Management en HTTP-statuskod: 400 när principen tillämpas i avsnittet inkommande trafik och 502 när principen tillämpas i avsnittet för utgående trafik.

I följande tabell visas alla möjliga orsaksvärden för ett valideringsfel tillsammans med möjliga meddelandevärden:

Relaterade principer

• Innehållsverifiering

Relaterat innehåll

Mer information om hur du arbetar med principer finns i:

• Självstudie: Transformera och skydda ditt API
• Principreferens för en fullständig lista över principinstruktioner och deras inställningar
• Principuttryck
• Ange eller redigera principer
• Återanvända principkonfigurationer
• Lagringsplats för principfragment
• Lagringsplats för principlekplats
• Principverktyg för Azure API Management
• Få Hjälp med Copilot för att skapa, förklara och felsöka principer