Copyright © 1997 RNDr. Libor Dostálek a Ing. Alena Kabelová
Formát textových zpráv přenášených v Internetu byl definován dvojicí norem RFC821/RFC822. Tato norma specifikuje formát textových zpráv pro elektronickou poštu.
Brzy se však ukázalo, že tento standard nevyhovuje požadavkům uživatelů, protože se mail ukázal jako vhodný prostředek pro posílání nejen holých textových zpráv, ale i pro posílání obrázků, zvuků, formátovaného textu, obecně binárních souborů, virtuální reality atp. V poslední době pak přibyl požadavek na posílání bezpečných zpráv, tj. šifrovaných i elektronicky podepsaných.
Princip vyměny zpráv se rychle rozšířil i za hranice elektronické pošty. Zprávy podobného formátu používá nejenom elektronická pošta, ale i news a protokol HTTP.
Lépe řečeno požadavky uživalelů rychle překročily možnosti nabízené normami RFC821/RFC822. Začaly se objevovat normy rozšiřující původní standard. Tato rozšíření se označují MIME.
Z historického hlediska původní norma umožňovala posílat zprávy psané ASCII-znaky, kde délka řádku byla omezena na 1000 znaků. Nepříjemná tedy byla skutečnost, že nebylo možné poslat text s diakritikou v našem případě text skutečně český a ne pouze cesky.
Posílání binárních souborů pomocí mailu se řešilo náhradní cestou. Soubory musely být před posláním předpřipraveny (šifrovány do sedmibitového tvaru) pomocí nějakého kódovacího programu. Kódovací program převedl binární soubor do tvaru, který vyhovoval RFC822. Příkladem takového kódovacího programu v Unixu je dvojice programů uuencode/uudecode.
Ještě před tím, než si popíšeme jednotlivé možnosti rozšíření zpráv, tak si zopakujeme jaký má zpráva v jednotlivých protokolech formát. Nejprve se zastavíme u elektronické pošty, ze které vše vzniklo.
Elektronická pošta je v Internetu základní aplikací. Slouží pro výměnu zpráv mezi uživateli Internetu. V praxi se však často setkáváme s případem, kdy si elektronickou poštou předávají data aplikace běžící na různých počítačích.
Většinou vždy, kdy úloha má dávkový charakter, je možné použít elektronickou poštu. Pro ty, kteří chtějí namítnout, že to není bezpečné, tak předběhneme a předem jim odpovíme, že pomocí rozšíření (např. S/MIME) je možné posílat zprávy i šifrované a elektronicky podepsané.
Zpráva elektronické pošty se skládá ze dvou částí:
Následující rámec schématicky znázorňuje zprávu elektronické pošty:
| Received: ................................. Received: ................................. Date: ................................... From: ........................................ Subject: ............................ To: ......................................... Message-Id: ............................ Text zprávy |
Zajímavá je hlavička Received:. Tuto hlavičku připisuje na počátek mailu každá mailova gateway (mailový server), kterou zpráva prochází. Takže čteme-li hlavičky Received: od spodu nahoru, tak zjistíme celou trasu, přes které mailové servery zpráva šla.
RFC822 zavádí hlavičky:
| Hlavička | Význam |
| Received: | Viz výše |
| From: | Odesilatel (autor) |
| Sender: | Vyřizuje (sekretářka) |
| Date: | Datum odeslání (Den, datum, čas a časová zóna) |
| Reply-To: | Odpověď zasílejte na |
| To: | Adresát |
| Cc: | Na vědomí |
| Bcc: | Na vědomí (tajná kopie - tato hlavička se před odesláním zruší) |
| Message-Id: | Identifikace zprávy |
| In-Reply-To: | Odpověď na |
| Keywords: | Klíčová slova charakterizující obsah |
| References: | Další odkazy |
| Subject: | Věc (krátká charakteristika obsahu zprávy) |
| Comments: | Komentář |
| Encrypted: | Šifrováno (zastaralé) |
| X- | Uživatelsky definovaná hlavička (uživatelem se rozumí autor software) Např. X-Mailer se často používá |
| Resent- | Při automatickém předávání (forward) zprávy se před původní hlavičky vloží řetězec Resent- Např.Resent-From nebo Resent-Cc apod. |
Všechny hlavičky mohou (v hodnotách nikoliv uprostřed klíčových slov) obsahovat komentář v kulatých závorkách. V komentáři se však nesmějí vyskytovat některé znaky - blíže viz RFC822.
V následujícím rámci je pak uveden příklad skutečné zprávy poslané elektronickou poštou:
Received: from mh.pvt.cz (mh.pvt.cz [194.149.105.36]) by cbu.pvtnet.cz
(8.8.5/8.7.3) with SMTP id PAA23028;
Wed, 16 Apr 1997 15:10:14 +0200 (MET DST)
Received: from ncc.ripe.net by mh.pvt.cz with SMTP id AA08008
(5.67b/IDA-1.5 for <registr@pvt.cz>);
Wed, 16 Apr 1997 15:05:09 +0200
Received: by ncc.ripe.net
id AA00228 (5.65a/NCC-2.41); Wed, 16 Apr 1997 13:55:02 +0200
Received: from mail.freedotnet.net by ncc.ripe.net with SMTP
id AA00215 (5.65a/NCC-2.41); Wed, 16 Apr 1997 13:55:00 +0200
Received: from jon.freedotnet.net ([208.215.186.129])
by homer.freedotnet.com (Netscape Mail Server v2.02) with ESMTP
id AAA105 for <local-ir@ripe.net>;
Wed, 16 Apr 1997 13:09:15 +0100
Reply-To: <jon.brody@freedotnet.net>
From: "Dr Jon Brody" <jon.brody@freedotnet.net>
To: <local-ir@ripe.net>
Subject: Re: Role?
Date: Wed, 16 Apr 1997 12:58:51 +0100
X-Mailer: Microsoft Internet Mail 4.70.1155
I'm sorry if this offends, but I'm not really that interested in being
constantly mailed (about 70 to date) about one person's problems.
Wouldn't our time be better spent working than being party to this?
If one has a problem with, tell them, please, not me.....
|
Čteme-li hlavičky Received od spodu nahoru, pak vidíme, že zpráva byla odeslána z počítače jon.freedotnet.net, pak ji zpracovával počítač homer.freedotnet.net (počítač mail.freedotnet.net je jen jiné jméno téhož počítače). Dále zpráva putovala na ncc.ripe.net, který ji předal na mh.pvt.cz a nakonec zkončila na cbu.pvtnet.cz.
Problém jak poslat elektronickou poštou zprávu obsahující jiná data než text psaný v kódu ASCII lze řešit dvojím způsobem:
Zpráva, kterou odesilatel předem připravil šifrovacím programem pgp
pgp -esa soubor
a následně ji jako text odeslal. Program pgp vyrobí zprávu a uzavře
ji do závorek
-----BEGIN PGP MESSAGE-----
a
-----END PGP MESSAGE-----
Subject: Tajna zprava Date: Sat, 19 Apr 1997 17:16:27 +0200 From: Libor Dostalek <dostalek@pvt.cz> To: alena@pvt.net -----BEGIN PGP MESSAGE----- Version: 2.6.3i hEwDVzIQ/0AACWUBAgCjg7Plko8fm4nrCZOn7LQprCvcMelrF7qr2N5S5adUHujQ hiUmcIMDK8zx+Cvm52lD68NZxKybexuaAESa+fMgpgAAALFXB4DlbeEWRHe6GwDz vYMsWPbK7+UFC9ZXeHsKc+c6iPokzMG/NWHf76/OLJXV3iKIKrfRFycA77Pu1G/X IccoMlAIfC29cqT7Y//q5TvYAwDoqpfIjoVaqz8dIjqy2G/2rf+acb4nyitLEtwL NE0huVXKsgenm39MqQp9A5W+dWzC8OcB2uHTzdzpQgNzJJ5JYf1/L75XZ0la3jyA t7HvXV6IPqQPIw0s0uChsEaKDPI= -----END PGP MESSAGE----- |
Následující příklad je odeslání zprávy připravené programem uuencode
$ cat soubor | uudecode soubor.uue | mail alena@pvt.net
který zprávu obalí závorkami:
begin práva soubor
a
end
Subject: Zprava kodovana uuencode
Date: Sat, 19 Apr 1997 17:12:26 +0200
From: System PRIVILEGED Account <root@pvt.cz>
To: alena@pvt.net
begin 644 soubor.uue
M(" U.C$R<&T@('5P(#$W(&1A>7,L(" Y.C$X+" @,2!U<V5R+" @;&]A9"!A
M=F5R86=E.B P+C U+" P+C P+" P+C P"E5S97(@(" @('1T>2!F<F]M(" @
*(" @(" @('<@"B @
end
|
Zkušený příjemce sice v těchto případech na první pohled pozná o jaký typ kódování se jedná, ale obecně nelze zaručit, že příjemce bez toho, aniž by se předem dohodl s odesilatelem, pozná co má se zprávou dělat.
V následujícím rámu je příklad takové zprávy. Odesilatel odesílá dvě alternativy téže zprávy. Jednu pro případ, že příjemce ji bude číst běžným textovým prohlížečem (editorem) a druhou alternativu pro případ, že zpráva bude čtena prohlížečem, který podporuje jazyk HTML.
Tyto informace nesou hlavičky začínající řetězcem "Content-", které specifikuje norma MIME. Objasnění významu těchto hlaviček je cílem následujícíh kapitol.
From: "Dr Jon Brody" <jon.brody@freedotnet.net> To: <local-ir@ripe.net> Subject: Re: Role? Date: Wed, 16 Apr 1997 12:58:51 +0100 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart" Content-Transfer-Encoding: 7bit Message-Id: <19970416120915085.AAA105@jon.freedotnet.net> Content-Length: 1095 This is a multi-part message in MIME format. ------=_NextPart Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'm sorry if this offends, but I'm not really that interested in being constantly mailed (about 70 to date) about one person's problems. Wouldn't our time be better spent working than being party to this? If one has a problem, tell them, please, not me..... ------=_NextPart Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <html><head></head><BODY bgcolor=3D"#FFFFFF"><p><font size=3D2 = color=3D"#000000" face=3D"Arial">I'm sorry if this offends, but I'm not = really that interested in being constantly mailed about 70 to date) = about one person's problems.<br><br>Wouldn't our time be = problem, tell them, please, not me.....<br><br><br></p> </font></body></html> ------=_NextPart-- |
News používá velmi podobný tvar svých zpráv. Podle RFC1036 jsou hlavičky rozděleny na:
| Hlavička | Význam |
| From: | Odesilatel (autor) |
| Date: | Datum odeslání (Den, datum, čas a časová zóna) |
| Newsgroups: | Skupina do které zpráva patří (Obdoba To: u mailu) |
| Subject: | Věc (krátká charakteristika obsahu zprávy) |
| Message-id: | Identifikace zprávy |
| Path: | Cesta (seznam serverů), kterou zpráva urazila od odesilatele - viz dále |
| Followup-To: | Skupiny, do kterých má být zpráva také odeslána (Obdoba Cc: u mailu) |
| Expires: | Datum do kdy má být zpráva udržována na serveru. Poté je zpráva zrušena. |
| Reply-To: | Mailová adresa odesilatele |
| Sender: | Vyřizuje (sekretářka) |
| References: | Další odkazy |
| Control: | Řídící hlavička. Pomocí této hlavičky se řídí komunikace mezi servery. Tato hlavička není určena pro komunikaci uživatele se serverem. |
| Distribution: | Tato hlavička zmenšuje počet serveru, na které bude zpráva distribuována. Zpráva bude šířena pouze na servery uvedené v této hlavičce. |
| Keywords: | Klíčová slova. |
| Summary: | Krátký obsah zprávy. |
| Approved: | Zpráva schválena (povolena k šíření). Tato hlavička se používá v moderovaných
konferencích. Jako parametr se uvede mail osoby, která zprávu povolila. |
| Lines: | Počet řádků těla zprávy. |
| Xref: | Přesná identifikace zprávy v konferenci (server konference:číslo) |
| Organization: | Zaměstnavatel uživatele |
Reálný příklad zprávy systému news následuje. Odeslal jsem obrázek formátu JPEG jako příspěvek do diskuzní skupiny - konference news.newusers.questions:
Path: pvtnet.cz!not-for-mail From: Libor Dostálek <dostalek@pvt.cz> Newsgroups: news.newusers.questions Subject: TEST JPG Date: Mon, 05 May 1997 14:42:12 +0200 Organization: PVT a.s. Lines: 330 Message-ID: <336DD5A4.6D8B@pvt.cz> NNTP-Posting-Host: libor.pvt.net Xref: pvtnet.cz news.newusers.questions:590527 Mime-Version: 1.0 Content-Type: image/jpeg; name="sit.jpg" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh ... 38mtHYTCtCirSPqrVzfTXI0V28Pjf8OrTcNj3leb+up0cKGJk0SM0HNE0WCE2GlDov4SiY3C kUj/2Q== |
V předchozím příkladu byla velice jednoduchá hlavička Path, protože zpráva byla serverem zpracována lokálně. V následujícím příkladu je příklad cesty z reálného života. Zprávu odeslal uživatel vladboro@mff.cuni.cz z počítače ns2.aladdin.net a já jako uživatel jsem si jí získal ze serveru pvtnet.cz. Všechny počítače oddělené vykřičníkem tvoří cestu zprávy news mezi těmito dvěma news-servery.
Path: pvtnet.cz!uunet!in2.uu.net!206.229.87.25!news-peer.sprintlink.net!news.sprintlink.net!Sprint!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!rill.news.pipex.net!pipex!Aladdin!aladdin.net!ns2.aladdin.net!not-for-mail From: Vladimir Borovicka <vladboro@mff.cuni.cz>; |
Záměrně jsem poslal jako příspěvek do konference zprávu obsahující obrázek (ne text), aby jste si mohli všimnout, že i news mohou obsahovat rozšiřující hlavičky MIME (začínají řetězcem Content-).
Podobně i zprávy news je možné posílat šifrované i elektronicky podepsané (Secure news - S/NEWS).
Obdobnou strukturu zprávy jako elektronická pošta používá i protokol HTTP. Avšak u protokolu HTTP má speciální význam první řádek záhlaví. V dotazu specifikuje metodu (GET, POST, HEAD, STATUS atp.) požadovaná data (např. jméno souboru) a verzi protokolu HTTP. Dále pak následují hlavičky, prázdný řádek a případně data zprávy.
V následujícím rámci uvádíme příklad dotazu v protokolu HTTP, který obsahuje pouze hlavičky a má prázdné tělo (prázdný řádek ukončující záhlaví však nesmí chybět - na obrázku to nelze dostatečně zdůraznit).
GET prirucka.htm HTTP/1.1 Host: info.pvt.net |
Odpověď v protokolu HTTP obsahuje jako první řádek tzv. stavový řádek specifikující verzi protokolu HTTP použitého serverem (musí být stejná nebo nižší než uvedl klient) a výsledkový kód, případně textový význam výsledkového kódu.
Data zprávy jsou od záhlaví opět oddělena právě jedním prázdným řádkem. Příklad je v následujícím rámci:
HTTP/1.0 200 OK Server: Netscape-FastTrack/2.01 Date: Fri, 18 Apr 1997 13:49:20 GMT Accept-ranges: bytes Last-modified: Wed, 26 Mar 1997 06:39:49 GMT Content-length: 1940 Content-type: text/html <HTML> <HEAD> <TITLE>Titulek</TITLE> </HEAD> <BODY> <H1>Kapitola</H1> ... </BODY> </HTML> |
Zatímco u elektronické pošty a u news jsme oddělovali hlavičky pošty (resp. news) od hlaviček MIME, tak v případě protokolu HTTP jsou hlavičky začínající řetězcem Content součástí specifikace protokolu HTTP.
Na rozdíl od elektronické pošty a news je protokol HTTP interaktivní. To umožňuje, aby se oba účastníci komunikace (klient a server) nejprve dohodli na kódování, kompresním algoritmu, jazyku atd. Takže ještě před tím než jsou data odeslána s příslušnou hlavičkou začínající řetězcem Content, tak protějšek nabízí jaké možnosti podporuje (hlavičkami začínajícími řetězcem Accept).
Přehled hlaviček HTTP/1.1:
| Hlavička | Vyznam |
| Accept: | Seznam podporovaných typů (anglicky medium)
Příklad: |
| Accept-Charset: | Seznam podporovaných znakových sad
Příklad: |
| Accept-Encoding: | Podporované kódování. Zpravidla se používá pro kompresi dat.
Příklad: |
| Accept-Language: | Podporavaný jazyk
Accept-Language: cz, en-gb;q=0.5 |
| Accept-Range: | Podporované množství přenášených dat |
| Age: | Čas po který může cache použít data |
| Allow: | Seznam podporovaných metod
Příklad: |
| Authorization: | Tato hlavička se používá pro autorizaci. Klient v této hlavičce uvádí informace, kterými prokazuje svou totožnost. |
| Cache-Control: | Tato hlavička se používá pro řízení dat v cache. |
| Content-Base: | Kořen absolutního URL. Používá-li se relativní URL, pak předsazením
obsahu této hlavičky před relativní URL vznikne absolutní URL. |
| Content-Encoding: | Použité kódování. Zpravidla použitý kompresní algoritmus.
Content-Encoding: gzip |
| Content-Language: | Použitý jazyk
Content-Language: en |
| Content-Length: | Velikost těla zprávy v bajtech. |
| Content-Location: | Zpráva je na uvedeném URL. |
| Content-MD5: | Kontrolní součet přenášené zprávy vytvořený algoritmem MD5 (RFC1864) |
| Content-Range: | Část zprávy (odeslaná serverem).
Příklad: Prvních 1000 bajtů zprvávy dlouhé 5555 bajtů: |
| Content-Type: | Typ přenášené zprávy
Příklad: |
| Date: | Den, datum, čas a časová zóna |
| ETag: | Definice tagu |
| Expires: | Čas po kterém zpráva v cache expiruje. |
| From: | Poštovní adresa odesilatele. |
| Host: | Specifikuje server (zejména virtuální). |
| If- | Hlavičky začínající If umožňují vydávat podmíněné požadavky. |
| Last-Modified: | Datum a čas poslední modifikace zprávy. |
| Location: | Přesměrování na jiné URL |
| Max-Forwarders: | Max. počet proxy na cestě mezi klientem a serverem (význam má pro metodu TRACE) |
| Pragma: | Hlavička pro uživatelsky definované potřeby. |
| Proxy-Authenticate: Proxy-Autorization: |
Obdoba hlaviček Authorization: a WWW-Authenticate:, které slouží k vyžádání a prokázání totožnosti klienta vůči originálnímu serveru. Hlavičky Proxy-Autorization: a Proxy-Authenticate: slouží pro vyžádání a prokázání totožnosti klienta vůči proxy serveru. |
| Public: | Server touto hlavičkou dává na vědomí seznam jím podporovaných metod.
Public: GET, PUT |
| Range: | Požadavak pouze na část zprávy.
Range: 500-999 |
| Refer: | Klient specifikuje serveru, odkud se o zprávě dozvěděl.
Refer: http://info.pvt.net |
| Retry-After: | V případě výpadku spojení se má opakovat pokus o opětovné navázání spojení za. |
| Server: | Informace o software použitém jako server.
Server: CERN/3.0 |
| Transfer-Encoding: | Kódovací algoritmus použitý pro přenos zpráv. Jelikož je HTTP osmibitový, tak tato hlavička není příliš častá. |
| Upgrade: | Klient specifikuje jaké další protokoly podporuje
Upgrade: SHTTP/1.3 |
| User-Agent: | Obsahuje informace o programu klienta.
User-Agent: CERN-LineMode/2.15 |
| Vary: | Změna typu dat. |
| Via: | Specifikuje cestu přes gatewaye a proxy. (Obdoba hlavičky Path u news). Každá proxy nebo gateway je povinna se do této hlavičky připsat. |
| Warning: | Upozornění. Chybové hlášení je obsaženo ve stavovém řádku (první řádek zprávy). Jsou-li třeba uvést další vysvětlující informace, pak se uvedou v této hlavičce. |
| WWW-authenticate: | V případě, že server vyžaduje autorizovaný přístup, pak v odpovědi
401 (Unauthorized) uvede hlavičku WWW-authenticate, kde uvede způsob jakým
má klient prokázat svou totožnost (např. způsob basic - klient se prokazuje
jménem a heslem).
Klient v odpovědi uvede hlavičku Authorization se způsobem a příslušným řetězcem, kterým prokazuje svou totožnost (v případě basic auth. řetězec obsahuje zakódované jméno a heslo pomocí base64) |
Z předchozí tabulky je zřejmé, že problematika MIME je do protokolu HTTP zcela organicky zapracována. Dále se v tomto textu nebudeme už zabývat problematikou protokolu HTTP. Naopak až budete studovat protokol HTTP, pak vám budou velmi užitečné informace uváděné v tomto textu.