A HTTP működése
 (→Potenciális zh-kérdések)  | 
			a (link a http://www.and.org/texts/server-http -re)  | 
			||
| (egy szerkesztő 4 közbeeső változata nincs mutatva) | |||
| 1. sor: | 1. sor: | ||
A HTTP-t remélhetőleg senkinek sem kell bemutatni.  | 
  A HTTP-t remélhetőleg senkinek sem kell bemutatni.  | 
||
| − | Egy tipikus tranzakció így néz ki:  | 
  + | Egy ''tipikus'' tranzakció így néz ki:  | 
Kliens:  | 
  Kliens:  | 
||
| 27. sor: | 27. sor: | ||
Content-Type: text/html  | 
  Content-Type: text/html  | 
||
</pre>  | 
  </pre>  | 
||
| + | |||
| + | (A [http://www.and.org/texts/server-http http://www.and.org/texts/server-http] oldalon olvashatunk arról, mennyire atipikusak is lehetnek a tranzakciók. Érdemes elolvasni.)  | 
||
Azt érdemes megfigyelni, hogy egy IP:port kombináción több virtuális webszerverünk is lehet a Host: headernek köszönhetően.  | 
  Azt érdemes megfigyelni, hogy egy IP:port kombináción több virtuális webszerverünk is lehet a Host: headernek köszönhetően.  | 
||
| 32. sor: | 34. sor: | ||
HTTPS esetén ugyanez nem működik, mert az SSL handshake megelőzi a HTTP-kérést, így a szerver nem tudja, melyik tanúsítványt mutassa; ha viszont nem ahhoz a szervernévhez tartozót mutatja, amelyikről a kliens le akar tölteni valamit, az egyrészt sechole, másrészt sopánkodik is miatta a böngésző.  | 
  HTTPS esetén ugyanez nem működik, mert az SSL handshake megelőzi a HTTP-kérést, így a szerver nem tudja, melyik tanúsítványt mutassa; ha viszont nem ahhoz a szervernévhez tartozót mutatja, amelyikről a kliens le akar tölteni valamit, az egyrészt sechole, másrészt sopánkodik is miatta a böngésző.  | 
||
| − | HTTPS esetén vagy minden hosztot külön IP:portra kell rakni, vagy minden virtuális hosztnak ugyanabba a domainbe kell tartoznia, és *.domain.com-ra érvényes tanúsítvány kell. (Minden kliens elfogadja?)  | 
  + | HTTPS esetén vagy minden hosztot külön IP:portra kell rakni, vagy minden virtuális hosztnak ugyanabba a domainbe kell tartoznia, és *.domain.com-ra érvényes tanúsítvány kell. (Minden kliens elfogadja? Állítólag az IE és az OE nem.)  | 
| + | |||
| + | Egy az SNI-ről szóló [http://weblogs.mozillazine.org/gerv/archives/2007/08/virtual_hosting_ssl_and_sni.html cikkben] azt boncolgatják, hogy ez a "Server Name Indication" nevű megoldás, amit egyébként az [http://www.rfc-archive.org/getrfc.php?rfc=3546 RFC3546] ír le, a jövőben megkönnyíti majd a https-es virtualhosztingot; egyelőre (2007-ben) azonban pl. Windows XP-re nem érhető el olyan IE-változat, ami támogatná, úgyhogy széles körben nem lehet használni. A Firefox2 állítólag tudja.  | 
||
| + | |||
| + | Szintén megoldás lehet, ha olyan tanúsítványt készítünk, amelyben a Subject Alternative Name mezőben felsoroljuk az összes olyan hosztnevet, amire érvényesnek kell lennie; viszont ehhez a tanúsítvány igénylésekor már tudnunk kell, melyek ezek a hosztok, és találnunk kell olyan CA-t, amelyik hajlandó aláírni ezt az öszvértanúsítványt (ez valószínűleg nem annyira nehéz, ha mindegyik hosztnév ugyanabba a domainbe esik).  | 
||
== Hibakódok ==  | 
  == Hibakódok ==  | 
||
| 88. sor: | 90. sor: | ||
* Milyen problémával kell számolnunk, ha http virtualhostingot használunk, és SSL-re is szükségünk van? Milyen megoldásai vannak a problémának?  | 
  * Milyen problémával kell számolnunk, ha http virtualhostingot használunk, és SSL-re is szükségünk van? Milyen megoldásai vannak a problémának?  | 
||
| − | ** A fejléc Host mezejének köszönhetően a szerver tudja, hogy melyik virtualhostot kell mutatnia a kliensnek. SSL használata esetén ez azért problémás, mert az SSL handshake a HTTP tranzakció előzz zajlik le, így a webszerver nem tudja, hogy melyik virtualhost tanusítványát mutassa az adott kliensnek. A problémára megoldás, ha az összes SSL-t használó virtualhost 1 domain alá tarozik, es a *.domain.com számára készül tanusítvány, vagy minden SSL-t használó virtualhost legyen megkülönböztethető {ip:port} alapján.  | 
  + | * Írja le egy tipikus HTTP-tranzakció során kicserélt alkalmazási rétegbeli üzeneteket! (Az üzenetek felépítése fontosabb, mint a konkrét tartalmuk.) Hogyan csoportosíthatók a szerver által küldött numerikus kódok?  | 
| − | * Írja le egy tipikus HTTP-tranzakció során kicserélt alkalmazási rétegbeli üzeneteket! (Az üzenetek felépítése fontosabb, mint a konkrét tartalmuk.)  | 
  ||
| − | ** GET üzenet  | 
  ||
| − | *** if-modified since (le kell-e egyáltalán tölteni)  | 
  ||
| − | *** host  | 
  ||
| − | *** user-agent (a nem megfelelő html rendereléseket elkerülő hackek használhatják)  | 
  ||
| − | *** accept-* (milyen típusú, nyelvű, stb. dokumentumot fogad el a felhasználó)  | 
  ||
| − | *** connection (kapcsolatra jellemző paraméterek, pl. keep-alive beállítása)  | 
  ||
| − | ** OK üzenet  | 
  ||
| − | *** date  | 
  ||
| − | *** server  | 
  ||
| − | *** last modified  | 
  ||
| − | *** content-length  | 
  ||
| − | *** keep-alive (oldalszám és időkorlát)  | 
  ||
| − | *** content-type  | 
  ||
A lap jelenlegi, 2013. április 12., 08:37-kori változata
A HTTP-t remélhetőleg senkinek sem kell bemutatni.
Egy tipikus tranzakció így néz ki:
Kliens:
GET / HTTP/1.0 If-Modified-Since: Thu, 14 Sep 2006 10:30:58 GMT Host: chardonnay.math.bme.hu User-Agent: NutScrape/1.0 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Connection: keep-alive
Erre a szerver:
HTTP/1.1 200 OK Date: Thu, 14 Sep 2006 22:46:45 GMT Server: Apache Last-Modified: Thu, 14 Sep 2006 22:46:00 GMT Content-Length: 6730 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html
(A http://www.and.org/texts/server-http oldalon olvashatunk arról, mennyire atipikusak is lehetnek a tranzakciók. Érdemes elolvasni.)
Azt érdemes megfigyelni, hogy egy IP:port kombináción több virtuális webszerverünk is lehet a Host: headernek köszönhetően.
HTTPS esetén ugyanez nem működik, mert az SSL handshake megelőzi a HTTP-kérést, így a szerver nem tudja, melyik tanúsítványt mutassa; ha viszont nem ahhoz a szervernévhez tartozót mutatja, amelyikről a kliens le akar tölteni valamit, az egyrészt sechole, másrészt sopánkodik is miatta a böngésző.
HTTPS esetén vagy minden hosztot külön IP:portra kell rakni, vagy minden virtuális hosztnak ugyanabba a domainbe kell tartoznia, és *.domain.com-ra érvényes tanúsítvány kell. (Minden kliens elfogadja? Állítólag az IE és az OE nem.)
Egy az SNI-ről szóló cikkben azt boncolgatják, hogy ez a "Server Name Indication" nevű megoldás, amit egyébként az RFC3546 ír le, a jövőben megkönnyíti majd a https-es virtualhosztingot; egyelőre (2007-ben) azonban pl. Windows XP-re nem érhető el olyan IE-változat, ami támogatná, úgyhogy széles körben nem lehet használni. A Firefox2 állítólag tudja.
Szintén megoldás lehet, ha olyan tanúsítványt készítünk, amelyben a Subject Alternative Name mezőben felsoroljuk az összes olyan hosztnevet, amire érvényesnek kell lennie; viszont ehhez a tanúsítvány igénylésekor már tudnunk kell, melyek ezek a hosztok, és találnunk kell olyan CA-t, amelyik hajlandó aláírni ezt az öszvértanúsítványt (ez valószínűleg nem annyira nehéz, ha mindegyik hosztnév ugyanabba a domainbe esik).
[szerkesztés] 1 Hibakódok
Több más internetes protokollhoz hasonlóan a HTTP-nél is háromjegyű hibakódokkal találkozunk, amelyek első jegyéből lehet következtetni a probléma lényegére. Inkább csak felsorolásszinten:
- 1-essel kezdődő: elvileg van ilyen, pl. egy kapcsolat protokoll-upgrade-je esetén lehetne használni. Látott már ilyet élő ember?
 -  2-essel kezdődő: nincs gond, a művelet sikerült.
- 200 OK
 - 201 Created
 - 202 Accepted
 - 203 Non-Authoritative Information
 - 204 No Content
 - 205 Reset Content
 - 206 Partial Content
 
 -  3-assal kezdődő: átirányítás
- 300 Multiple Choices
 - 301 Moved Permanently
 - 302 Found
 -  303 See Other
- POST eredménye lehet
 
 - 304 Not Modified
 - 305 Use Proxy
 - 306 volt, de megszűnt
 - 307 Temporary Redirect
 
 -  4-essel kezdődő: kliensoldali hiba
- 400 Bad Request
 - 401 Unauthorized
 -  402 Payment Required
- "Reserved for future use"
 
 - 403 Forbidden
 - 404 Not Found
 - 405 Method Not Allowed
 - 406 Not Acceptable
 - 407 Proxy Authentication Required
 - 408 Request Timeout
 - 409 Conflict
 - 410 Gone
 - 411 Length Required
 - 412 Precondition Failed
 - 413 Request Entity Too Large
 - 414 Request-URI Too Long
 - 415 Unsupported Media Type
 - 416 Requested Range Not Satisfiable
 - 417 Expectation Failed
 
 -  5-össel kezdődő: szerveroldali hiba
- 500 Internal Server Error
 - 501 Not Implemented
 - 502 Bad Gateway
 - 503 Service Unavailable
 - 504 Gateway Timeout
 - 505 HTTP Version Not Supported
 
 
[szerkesztés] 2 Potenciális zh-kérdések
- Milyen problémával kell számolnunk, ha http virtualhostingot használunk, és SSL-re is szükségünk van? Milyen megoldásai vannak a problémának?
 - Írja le egy tipikus HTTP-tranzakció során kicserélt alkalmazási rétegbeli üzeneteket! (Az üzenetek felépítése fontosabb, mint a konkrét tartalmuk.) Hogyan csoportosíthatók a szerver által küldött numerikus kódok?