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.
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í:
| 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:
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----- |
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.
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-- |
| 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).
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.