Arhitectura Apache include: un kernel simplu, un strat dependent de platformă (APR) și module. Orice aplicație pentru Apache - chiar și cea mai simplă, discutând pagina "implicită" a Apache "A lucrat" - folosește mai multe module. Apache utilizatorii nu au nevoie să știe acest lucru, dar pentru dezvoltatorul de programe, înțelegerea modulelor și API-ului modulului Apache este cheia pentru a lucra cu Apache. Cele mai multe, dar nu toate, module sunt asociate cu diferite aspecte ale procesării cererii HTTP. Este rar faptul că modulul trebuie să funcționeze cu fiecare aspect al HTTP: cum ar fi httpd (Apache). Avantajul abordării modulare este că vă permite să concentrați modulul pe o anumită sarcină, în timp ce ignorați alte aspecte ale HTTP care nu sunt relevante pentru această sarcină.
În acest articol, descriem arhitectura procesării cererii Apache și arătăm modul în care modulul poate intercepta controlul diferitelor părți ale ciclului de procesare a interogărilor.
Formula cea mai simplă a unui server web este un program care așteaptă cereri HTTP și returnează răspunsurile când se primește o cerere. Aceasta este principala sarcină în Apache, așa-numitul nucleu al serverului web. Pentru fiecare cerere HTTP, generatorul de conținut trebuie pornit. Unele module pot înregistra generatoare de conținut prin definirea funcțiilor care fac referire la un handler care poate fi configurat de direcțiile SetHandler sau AddHandler în httpd.conf. Aceste interogări pentru care generatorul unui modul nu este furnizat sunt procesate de un generator standard care returnează pur și simplu fișierul solicitat direct din sistemul de fișiere. Modulele care implementează unul sau mai multe generatoare de conținut sunt cunoscute ca generatoare de conținut sau module de procesare.
Iată câteva faze de procesare a solicitării înainte ca conținutul să fie generat. Ele sunt folosite pentru a verifica și a modifica eventual antetele de cerere și pentru a determina ce să facă cu interogarea. De exemplu:
Adresa URL a solicitării trebuie comparată cu datele de configurare pentru a determina ce generator de conținut trebuie utilizat.
Este necesar să se determine fișierul la care se referă adresa URL a solicitării. O adresă URL poate accesa atât un fișier statistic, cât și un script CGI sau orice altceva care poate fi folosit pentru a genera conținut.
Dacă conținutul este disponibil, mod_negotiation va găsi versiunea resursei care se potrivește cel mai bine cu setările browserului. De exemplu, paginile de ajutor Apache sunt afișate în limba în care cererea a fost primită din browser.
Regulile pentru accesarea și identificarea modulelor sunt verificate pentru a respecta regulile de acces la server și se stabilește dacă utilizatorul are dreptul de a primi ceea ce a solicitat.
mod_alias sau mod_rewrite pot schimba adresa URL din cerere.
În plus, există și o fază de logare a interogării, care este executată după ce generatorul de conținut trimite un răspuns la browser.
Modulul poate încorpora propriile dispozitive de manipulare în oricare dintre aceste cârlige. Modulele care prelucrează date în faze înainte de a genera conținut sunt cunoscute ca module de metadate. Cei care lucrează cu logare sunt cunoscuți ca module de logare.
Ceea ce am descris mai sus este în esență arhitectura unui server web. Singura diferență este în detalii, dar fazele prelucrării cererii: metadatele-> generatorul de conținut-> logare sunt comune.
Principala inovație în Apache 2 este transformarea acestuia dintr-un server web simplu (cum ar fi Apache 1.3 și alții) într-o platformă puternică, care este un lanț de filtre. Acesta poate fi reprezentat ca o axă de date perpendiculară pe axa procesării cererii. Datele solicitate pot fi procesate de filtrele de intrare înainte de generatorul de conținut, iar răspunsul serverului poate fi procesat de filtrele de ieșire înainte de a fi trimise clientului. Filtrele permit pre-filtrarea și prezentarea mai eficientă a datelor de procesare, separând aceste faze de generarea conținutului. Exemplu de filtre: procesare pe partea de server (SSI), procesare XML și XSLT, compresie gzip și criptare (SSL).
Înainte de a începe o discuție despre modul în care modulul este încorporat în orice etapă de prelucrare a cererii / date, să se concentreze asupra unui singur punct, care cauzează adesea confuzie în rândul dezvoltatorilor începători Apache module: și anume prelucrarea -Ordinul.
Axa de procesare a solicitărilor este liniară: fazele apar într-o ordine strictă. Dar va apărea o confuzie pe axa datelor. Pentru eficiență maximă, ordinul se modifică, astfel încât generatorul și filtrele nu sunt executate într-o secvență strict specificată. De exemplu, în general, nu puteți transfera nimic la filtrul de intrare și așteptați să îl primiți în generatorul sau în filtrele de ieșire.
În centrul de procesare este un generator de conținut, care este responsabil pentru obținerea datelor din stivele de filtre de intrare și pune datele pe stiva filtrului de ieșire. Când generatorul sau filtrul trebuie să proceseze întreaga solicitare, trebuie să facă acest lucru înainte ca datele să fie trimise în lanț (generatorul sau filtrele de ieșire) sau înainte de a returna datele înapoi la filtrul de intrare.
Acum avem o idee generală despre prelucrarea cererii în Apache și putem continua să vorbim despre modul în care modulele fac parte din această procesare. Structura modulului apache este descrisă de mai multe câmpuri și funcții de date (opționale):
modulul AP_MODULE_DECLARE_DATA my_module = <
STANDARD20_MODULE_STUFF,
my_dir_conf,
my_dir_merge,
my_server_conf,
my_server_merge,
my_cmds,
my_hooks
>;
Funcția modulului care creează cârligele de procesare a solicitărilor, ultimul din această structură:
static void my_hooks (apr_pool_t * pool) / * crearea cârligelor necesare pentru procesarea interogării * /
>
În funcție de ce părți din interogarea modulului nostru este interesat, trebuie să creați cârligele corespunzătoare. De exemplu, un modul care implementează un generator de conținut (manipulator) are nevoie de un cârlig de manipulare, cum ar fi:
ap_hook_handler (my_handler, NULL, NULL, APR_HOOK_MIDDLE);
Acum, apelatorul meu va fi sunat când procesarea cererii ajunge la faza de generare a conținutului. Cârligele altor faze de interogare sunt similare; De asemenea, uneori utilizați unul dintre:
ap_hook_post_read_request Prima șansă de procesare a solicitării după ce este acceptată.
ap_hook_fixups Ultima șansă de a procesa o solicitare înainte de generarea conținutului.
ap_hook_log_transaction Cârlig de înregistrare.
Între post_read_request și reparații, există mai multe alte cârlige create pentru scopuri specifice: de exemplu, modulele de acces și de autentificare au cârlige de verificare a accesului. Toate cârligele au exact același aspect ca și prelucrarea cârligului. Pentru mai multe informații, consultați http_config.h
Prototipul procesorului oricărei faze:
static int my_handler (request_rec * r) <
/ * cererea de procesare * /
>
request_rec este structura principală a datelor din Apache, stocând toate datele de solicitare HTTP.
Valoarea returnată a my_handler poate fi:
în regulă
my_handler a gestionat cu succes cererea. Faza de procesare este completă.
RESPINS
my_handler nu este interesat de interogare. Lăsați-i pe alți manipulanți să se ocupe de ea.
Un cod HTTP
A apărut o eroare în timpul procesării cererii. Acest lucru modifică modul în care cererea este procesată: procesarea normală este terminată, iar serverul returnează ErrorDocument în schimb.
Filtrele sunt, de asemenea, înregistrate în funcțiile my_hooks, dar API-ul este puțin diferit:
ap_register_output_filter ("my-output-filter-name", my_output_filter,
NULL, AP_FTYPE_RESOURCE);
ap_register_input_filter ("my-input-filter-name", fișierul meu_input_filter,
NULL, AP_FTYPE_RESOURCE);
cu următoarele prototipuri de funcții de filtrare
my_output_filter apr_status_t statică (ap_filter_t * f, apr_bucket_brigade * bb) / * Citirea blocuri de date, prelucrarea și transmiterea filtrului următor * /
retur APR_SUCCESS;
>
statică apr_status_t my_input_filter (ap_filter_t * f, apr_bucket_brigade * bb,
modul ap_input_mode_t, blocul apr_read_type_e, apr_off_t nbytes) <
/ * obținerea blocului din următorul filtru, procesarea, returnarea blocului la bb * /
retur APR_SUCCESS;
>
Funcții de filtrare a reveni APR_SUCCESS dacă totul merge bine, fie în mod explicit, cum ar fi cele de mai sus, fie ca un cod de retur din filtrul următor sau prin apelarea ap_get_brigade ap_pass_brigade. Documentația API este în util_filter.h.
Structura centrală care descrie solicitarea HTTP este request_rec. Acesta este creat atunci când Apache acceptă solicitarea și este furnizat tuturor funcțiilor procesării cererii, așa cum se arată mai sus în prototipul my_handler. În filtrul de conținut, request_rec este disponibil ca f-> r.
request_rec este o structură uriașă care conține, direct sau indirect, toate datele necesare în timpul procesării cererii. Orice manipulator de metadate funcționează prin obținerea și modificarea câmpurilor în request_rec; astfel încât generatorul de conținut și filtrele acționează, de asemenea, procese I / O suplimentare și manipulatorul de lemne se comportă ei înșiși. Pentru o descriere completă, consultați fișierul header httpd.h.
Încheiem acest articol discutând pe scurt utilizarea cererii_rec. De asemenea, trebuie să vă uitați la API sau alte articole care descriu detaliile utilizării acestei structuri.
Iată o scurtă listă de răspunsuri la întrebările frecvente:
Bazinul de cerere r-> pool este disponibil pentru toate resursele create și are durata de viață a solicitării.
Antetele de solicitare și de răspuns sunt disponibile în r-> headers_in și r-> headers_out, respectiv. Ele sunt de tip apr_table_t și sunt gestionate de funcțiile apr_table, cum ar fi apr_table_get și apr_table_set.
Câmpul de manipulare determină ce manipulare este în prezent în acțiune. Generatoarele de conținut ar trebui să le verifice și să revină imediat DECLINE dacă nu se potrivește.
Câmpurile input_filter și output_filter pot fi utilizate ca descriptori de I / O, numai în modulul de filtrare. I / O la nivel înalt (transferat de la apache 1.x) este disponibil pentru generatoare de conținut, dar nu pentru filtre.
directivele de configurare sunt disponibile la per_dir_config domeniu și pot fi obținute prin utilizarea ap_get_module_config (ap_set_module_config, de asemenea, deși ar trebui să fie destul de inadecvat procesare a cererii de cc).
Alte structuri de date kernel sunt disponibile ca r-> conexiune (structura de conexiune), r-> server (structura serverului) și așa mai departe. Configurațiile lor sunt, de asemenea, disponibile la cerere.
Câmpul opțional de configurare request_config este actualizat pentru fiecare solicitare și stochează datele de solicitare între fazele de procesare ale cererii curente.