Hoe ’n vorentoe-proxy ’n pasgemaakte API-opskrifkop hanteer

’n API kan sy weergawe in ’n pasgemaakte versoekveld soos API-Version dra. ’n Gewone deurgee-proxy behoort nie daardie veld te laat vaar net omdat die naam onbekend is nie. HTTP vereis dat onherkende velde deurgestuur word, tensy ’n gedefinieerde uitsondering of ’n opgestelde beleid geld.

Die Connection-veld is een so ’n uitsondering. Vergelyk hierdie voorbeeldversoeke:

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

Hier is die API-veld nie as plaaslik tot hierdie verbinding aangewys nie. In die volgende voorbeeld verander die sender sy omvang uitdruklik:

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

’n Deurgee-proxy verwyder velde wat deur Connection genoem word voordat dit deurstuur, en verwyder of vervang die verbinding-spesifieke instruksies self. ’n Toepassing-opskrifkop wat vir die oorsprong bedoel is, behoort dus nie in daardie tokenlys te verskyn nie.

Vind die punt waar die veld verander

Vergelyk die versoek wat die kliënt opgestel het, die velde wat die proxy ontvang en deurstuur, en wat die oorsprong ontvang het. ’n Kliënt kan ’n opskrifkop weglaat voordat die proxy dit sien; ’n opgestelde filter kan dit doelbewus verwyder; ’n bediener kan ’n versoek verwerp omdat ’n opskrifkopgrens oorskry is.

Moenie stilswyende verwydering aflei bloot uit ’n drempel vir opskrifkopgrootte wat in ’n ou ontplooiing gerapporteer is nie. Grense en verwerpingsgedrag hoort by die werklike komponente en konfigurasie. Hou die HTTP-antwoord en die relevante logs by die waarneming.

Vir end-tot-end HTTPS binne ’n gewone CONNECT-tonnel kan die proxy nie die innerlike API-veld lees en selektief verwyder nie. Opskrifkop-inspeksie hoort dan by die TLS-eindpunte of by ’n uitdruklik vertroude inspeksie-tussenparty.