Fejlécek, törzs és tartalomtípusok

Célok

A lecke végére meg tudod különböztetni a fejléceket és a törzset, el tudod magyarázni a Content-Type és az Accept szerepét, és érted, miért ugyanaz a szolgáltatás adhat HTML-oldalt embernek és adatot programnak.

Miért kellenek fejlécek?

A kérés és a válasz kezdősora kevés: nem mondja meg, milyen formátumú a törzs, mennyi ideig használható a válasz, ki kéri, vagy milyen nyelven. Ha minden ilyen információt a címbe vagy a törzsbe kellene zsúfolni, a kettő összekeveredne. A HTTP ezért két rétegre bontja az üzenetet: a fejlécek az üzenetről szóló kiegészítő információt hordozzák, a törzs (body) pedig magát a tartalmat.

Az üzenet felépítése

flowchart TB
    K[Kezdősor: metódus és cél, vagy státuszkód] --> F[Fejlécek: név és érték]
    F --> U[Üres sor]
    U --> T[Törzs, ha van]

A fejléc név: érték formájú sor; a nevek nem érzékenyek a kis- és nagybetűre. (A HTTP/1.1-es kimenetekben Content-Type áll, a HTTP/2 viszont kisbetűs neveket használ: content-type.) A törzs lehet egy űrlap adata, JSON-dokumentum, HTML, kép vagy bármilyen fájl. Nem minden üzenetnek van törzse: a szokásos GET-kérésnek nincs, a 204 No Content válasznak sem.

Content-Type: mit tartalmaz a törzs?

A Content-Type fejléc megmondja, milyen formátumú a törzs. A formátumot médiatípusnak (media type, korábban MIME-típus) hívjuk: típus/altípus alakú.

Médiatípus	Jelentése
text/html	HTML-dokumentum
text/plain	egyszerű szöveg
text/css	stíluslap
application/json	JSON-adat
image/png, image/jpeg	képek
application/pdf	PDF-dokumentum

Az utána írt charset=utf-8 a szöveg karakterkódolását adja meg. A típus befolyásolja, hogyan értelmezi a kliens a kapott bájtokat: ugyanaz a szöveg HTML-ként oldalként, sima szövegként forráskódként jelenik meg.

A Content-Type a küldő állítása, nem garancia: a tartalomnak ténylegesen meg kell felelnie. Kérésben is használjuk, amikor törzset küldünk:

$ curl -i -X POST http://localhost:8080/jelentkezesek \
    -H 'Content-Type: application/json' -d '{"kurzus":"webprog"}'

A szerver ebből tudja, hogy JSON-t kell értelmeznie. A Content-Type leíró információ, nem jogosultság: a szervernek ettől még ellenőriznie kell, értelmes és megengedett-e a kérés.

Accept: milyen választ szeretnék?

Az Accept fejlécet a kliens küldi, és jelzi vele, milyen formátumú választ tud fogadni. Ez a tartalomegyeztetés (content negotiation) alapja: ugyanaz a cím többféle változatban is elérhető lehet. Kipróbálva a kipróbáló szerveren:

$ curl -i http://localhost:8080/api/kurzusok -H 'Accept: application/json'
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
...
[{"id":"webprog","cim":"Webprogramozás 1.",...}]

$ curl -i http://localhost:8080/api/kurzusok -H 'Accept: text/html'
HTTP/1.1 406 Not Acceptable
Content-Type: text/plain; charset=utf-8
...
Csak JSON érhető el

A második kérésre a szerver nem tud az igényhez illő változatot adni, ezért 406 Not Acceptable választ küld. (Nem minden szerver választ így: sokan a nekik tetsző alapváltozatot adják, ha az Accept nem teljesíthető.) A két fejléc ezért nem felcserélhető:

Fejléc	Ki küldi?	Mit fejez ki?
Content-Type	kliens vagy szerver	A küldött törzs formátuma
Accept	kliens	A kért válasz kívánt formátuma
Location	szerver	Új vagy átirányított erőforrás címe

Más fejlécek, más feladatok

A fejlécek többféle célt szolgálnak:

Terület	Példák	Hol tárgyaljuk?
Tartalom	Content-Type, Content-Length, Content-Language	ez a lecke
Irányítás	Location	a 2. fejezet HTTP-státuszkódokról szóló leckéje
Gyorsítótárazás	Cache-Control, ETag	10. fejezet
Állapot, azonosítás	Cookie, Set-Cookie, Authorization	7. fejezet
Böngészőbiztonság	Content-Security-Policy, Strict-Transport-Security	8. fejezet

Egyelőre elég annyit tudni, hogy a fejlécek nem az oldal vizuális „díszletei”, hanem a webes működés gépileg olvasható része. Sok későbbi témának (bejelentkezés, gyorsítótár, biztonság) a fejlécek az eszköze.

Embernek szánt oldal, gépnek szánt adat

Ugyanaz a webes szolgáltatás adhat HTML-oldalt a böngészőnek és JSON-adatot egy másik programnak. Mindkettő HTTP-válasz törzse; a különbséget a Content-Type jelzi. A böngésző fejlesztői eszközének hálózati paneljén (Network) kattintás után megnézhető egy kérés minden fejléce és a törzs; a curl -i ugyanezt mutatja parancssorból.

Végigvezetett példa: a kurzuslista kétféleképpen

A Kurzuspont kurzuslistája két módon is lekérhető:

Kérés	Accept	Válasz Content-Type	Törzs
A böngésző megnyitja a listát	text/html	text/html	oldal, amit az ember olvas
A mobilalkalmazás lekéri az adatot	application/json	application/json	strukturált adat, amit a program feldolgoz

A 2. fejezetben ez még csak annyit jelent, hogy a cím és a fejléc együtt határozza meg, mit kapunk. Az 5. fejezetben az adat formátumát és a felület tervezését részletesen megnézzük.

Gyakori tévhitek

Állítás	Pontosítás
„A fejléc az oldal tetején látható szöveg.”	A HTTP-fejléc az üzenet része, nem a dokumentum vizuális fejléce.
„A Content-Type létrehozza a formátumot.”	A küldő jelzi vele a formátumot; a tartalomnak meg kell felelnie.
„Minden kérésben van törzs.”	A szokásos GET-nek nincs.
„Az Accept és a Content-Type ugyanaz.”	Az egyik a kért választ, a másik a küldött törzset írja le.
„A fejlécnevek kis- és nagybetűre érzékenyek.”	Nem azok; a HTTP/2 kisbetűs alakot használ.

Röviden

• A fejlécek az üzenet kezelésére vonatkozó metaadatok, a törzs a tartalom.
• A Content-Type a küldött törzs formátuma, az Accept a kért válaszé.
• A médiatípus típus/altípus alakú; a charset a karakterkódolást adja.
• Ugyanaz a szolgáltatás kiszolgálhat embert (HTML) és programot (JSON).

Ellenőrző kérdések

1. Mi a különbség a fejléc és a törzs között?
2. Milyen fejlécet használ a kliens a kívánt válaszformátum jelzésére?
3. Mi történhet, ha az Accept olyan formátumot kér, amelyet a szerver nem tud adni?
4. Miért nem elég a Content-Type a kérés biztonságához?

Tanulási források

• Overview of HTTP (MDN) — a fejlécek és a törzs szerepe angolul.
• HTTP Semantics, RFC 9110 — a fejlécek és a tartalomegyeztetés hivatalos leírása.