Standaard voor het toevoegen van meerdere waarden van een enkele HTTP-header aan een verzoek of antwoord

Als ik een lijst met waarden als HTTP-header wil toevoegen, is er dan een standaardmanier om dit te doen? Ik kon niets vinden (dat ik gemakkelijk kon begrijpen) in RFC 822. Bijvoorbeeld, is
door komma’s gescheiden waarden standaard of door puntkomma’s gescheiden waarden. Is er überhaupt een standaard?

Voorbeeld:

Key: value1;value2;value3

Antwoord 1, autoriteit 100%

Bekijk de HTTP-specificatie RFC 2616waar staat:

Meerdere berichtkopvelden met
dezelfde veldnaam KAN aanwezig zijn in
een bericht als en slechts als de volledige
veldwaarde voor dat kopveld is
gedefinieerd als een door komma’s gescheiden lijst
[d.w.z. #(waarden)]. Het MOET mogelijk zijn
om de meerdere koptekstvelden te combineren
in één “veldnaam: veldwaarde”
paar, zonder de semantiek te veranderen
van het bericht, door elke toe te voegen
volgende veldwaarde naar de eerste,
elk gescheiden door een komma. De bestelling
in welke kopvelden met hetzelfde
veldnaam worden ontvangen is daarom
belangrijk voor de interpretatie van
de gecombineerde veldwaarde, en dus a
proxy MOET de volgorde van NIET veranderen
deze veldwaarden wanneer een bericht is
doorgestuurd.

Dit betekent dat je dezelfde header meerdere keren in een reactie met verschillende waarden kunt verzenden, zolang die waarden maar met een komma aan elkaar kunnen worden toegevoegd. Dit betekent ook dat u meerdere waarden in een enkele kop kunt verzenden door ze met komma’s samen te voegen.

Dus in jouw geval zal het zijn:

Key: value1,value2,value3

Antwoord 2, autoriteit 16%

in ieder geval @marc-novakowski, je verkleint het “probleem” 🙂

normaal gesproken (per HTTP-specificatie) scheiden we elke waarde van de andere met een komma ‘,’

maar we zullen een eenvoudig geval onderzoeken:

Cookie-set: language=pl; expires=Sat, 15-Jul-2017 23:58:22 GMT; path=/; domain=x.com   
Cookie-set: id=123 expires=Sat, 15-Jul-2017 23:58:22 GMT; path=/; domain=x.com; httponly   

hoe voeg je zulke koppen samen als de waarden van elkaar worden gescheiden door komma’s – geval wanneer coma kan verschijnen ???

dan is de verantwoordelijkheid van de “klant” om kiezenen de strategiete bepalen, bijv. laten vallen, samenvoegen(indien samenvoegen hoe)?

kijk alstublieft naar de Mozilla-implementatie van nsHttpHeaderArray

https://github .com/bnoordhuis/mozilla-central/blob/master/netwerk/protocol/http/nsHttpHeaderArray.h#L185

mozilla kiest er in dit geval voor om een scheidingsteken voor nieuwe regels ‘\n’te gebruiken (voor bepaalde namen van koptekstvelden)

Ik moedig u aan om, wanneer u met een dergelijke situatie wordt geconfronteerd, te zoeken in gemeenschappelijke bestaande oplossingen – omdat deze een bekend schema bieden

markeert uitleg:

Cookies maken geen deel uit van de HTTP-standaard. Cookies worden gedefinieerd in een
eigen RFC, 6265 (formeel 2965 en 2109). Zelfs alleen de HTTP 2 RFC
noemt cookies maar definieert ze niet als onderdeel van de standaard. –
@mecki 25 aug om 18:56

kijk nog een keer voor zin:

per HTTP-specificatie scheiden we elke waarde van elkaar met een komma ‘,’ – er is hier geen woordcookie 🙂

misschien moeten we precies aangeven dat we het hier hebben over HEADER FIELD(s – wanneer we ze herhalen) “Cookie-set” is een header velden het heeft waarde .. die waarde die we beschouwen als een “COOKIE/S” – dus de client/server-implementatie zou dergelijke “COOKIE/S” moeten afhandelen

ZIE WAARDEN OF NAAMPAREN 🙂 IN HTTP 1/1 SPEC

https://datatracker.ietf.org/doc/html /rfc7230#section-3.2.2


Antwoord 3, autoriteit 8%

Niet alle waarden met dezelfde veldnaam kunnen worden gecombineerd in veldwaardenlijst. Bijvoorbeeld, in rfc 7230 we kunnen

lezen

Opmerking: in de praktijk, het “SET-COOKIE” -kopveld ([RFC6265]) vaak
verschijnt meerdere keren in een reactiebericht en gebruikt de
Lijst Syntaxis, het overtreden van de bovenstaande vereisten op meerdere koptekst
velden met dezelfde naam. Omdat het niet kan worden gecombineerd in een
Single Field-waarde, ontvangers zouden ‘set-cookie’ als een moeten verwerken
Speciaal geval tijdens het verwerken van kopvelden. (Zie bijlage A.2.3
van [kri2001] voor details.)

Other episodes