CONTENT_LENGHT = 24 CONTENT_TYPE = APPLICATION/x-www-form-urlencoded

Standard utgang ( STDOUT)

Etter at CGI-skriptet er ferdig med å behandle dataene mottatt fra serveren, må det sende svaret til serveren. For å sende dataene til serveren, må den sende dem til standard utdatafilbeskrivelse STDOUT. Generelt er dataene som skriptet sender tilbake til serveren et HTTP-svar, inkludert en header, etterfulgt av en tom linje, og etterfulgt av resten av svaret. Vanligvis er utdataene til et skript HTML-dokumentene som genereres av skriptet.

Skriptet er direkte respons på nettleseren

Vanligvis produserer skriptet et svar som serveren tolker og sender tilbake til nettleseren. Fordelen med å sende skriptets utdata til serveren er at skriptet ikke trenger å sende hele HTTP-headeren for hver forespørsel. Noen skript laster imidlertid av serveren og sender utdataene direkte til nettleseren. For å skille skript som sender data direkte til nettleseren fra skript som sender det til serveren, krever CGI-protokollen at navnene på skript som sender data direkte til nettleseren begynner med bokstavene nph-(som forteller serveren Ikke for å analysere overskriften - ikke initialiser overskriften). Hvis skriptnavnet starter slik, vil ikke serveren sette inn overskriften i skriptdataene. I dette tilfellet hviler ansvaret på selve manuset.

CGI-titler

Som du lærte tidligere, starter produksjonen av et skript med en overskrift. Denne overskriften består av en tekstlinje i samme format som HTTP-overskriften, som slutter med en tom linje (en linje som kun inneholder CRLF). Hvis skriptutgangen inneholder andre overskrifter enn direktiver til serveren, så sender serveren disse overskriftene til nettleseren som svar på forespørselen. Den nåværende CGI-spesifikasjonen definerer tre direktiver:

• INNHOLDSTYPE
• PLASSERING
• STATUS

Felt Innholdstype i CGI-overskriften spesifiserer typen/utvidelsen av MIME-data som skriptet sender tilbake til nettleseren. Vanligvis produserer skript et HTML-dokument som utdata. I dette tilfellet CGI-overskriften Innholdstype inneholder følgende:

Innholdstype: tekst/html

Felt plassering topptekst angir dokumentet. Skript bruker vanligvis feltet plassering for å angi plasseringen av dokumentet. Hvis dokumentet ikke er plassert på serveren og innholdet i feltet er en URL, omdirigerer serveren nettleseren til riktig node. Hvis dokumentet er på serveren og feltet er en virtuell bane, sender serveren dette dokumentet til nettleseren. For å peke på et dokument på en ekstern server, kan overskriftsfeltet for eksempel se slik ut:

Sted: http://www.cetis.ru

Felt Status Overskriften inneholder HTTP-statusverdien som serveren sender fra skriptet til nettleseren. Serveren som kaller skriptet bruker forskjellige HTTP-statuskoder. Det kan være lurt å sende statuskoden direkte til nettleseren, spesielt hvis det oppstår feil.

Følgende eksempel illustrerer den typiske utgangen et skript vil produsere når data sendes til en server. Etter at dataene når serverprogrammet, vil serveren videresende dataene til nettleseren:

Innholdstype: tekst/html Dette er kroppen generert av CGI-skriptet ditt.

Legg merke til den tomme linjen mellom de første linjene. Denne tomme linjen er helt nødvendig. Følgende C-kodebit oppretter dokumentet ovenfor ved å bruke funksjonen printf:

// Mer kode ovenfor: printf("Innholdstype: text/html\n"); printf("\n"); // Sørg for å inkludere denne tomme linjen printf(" \n"); printf(" \n"); printf(" \n"); printf("\n"); printf(" \n"); printf("Dette er kroppen generert av CGI-skriptet ditt.\n"); printf("\n"); printf("\n"); // Mer kode nedenfor...

Takket være World Wide Web kan nesten hvem som helst gi informasjon på nettet i en form som er lett for øynene og som kan spres bredt. Du har uten tvil surfet på Internett og sett andre sider, og nå vet du sikkert at skumle akronymer som "HTTP" og "HTML" ganske enkelt er en forkortelse for "Web" og "måten informasjon uttrykkes på Internett." Du har kanskje allerede litt erfaring med å presentere informasjon på Internett.

Internett har vist seg å være et ideelt medium for å distribuere informasjon, noe man kan se av dets enorme popularitet og utbredte utvikling. Selv om noen har stilt spørsmål ved nytten av Internett og tilskriver dens utbredte utvikling og popularitet hovedsakelig påtrengende reklame, er Internett unektelig et viktig medium for å presentere all slags informasjon. Ikke bare er det mange tjenester tilgjengelig for å gi oppdatert informasjon (nyheter, vær, direktesendte sportsbegivenheter) og referansemateriale elektronisk, det er også betydelige mengder andre typer data tilgjengelig. IRS, som distribuerte alle 1995 selvangivelsesskjemaer og annen informasjon via World Wide Web, innrømmet nylig å ha mottatt fanmail for nettstedet. Hvem hadde trodd at skattemyndighetene noen gang ville motta fanmail? Dette var ikke fordi nettstedet hans var godt designet, men fordi det hadde vist seg å være et virkelig nyttig verktøy for tusenvis, kanskje millioner, av mennesker.

Hva gjør nettet unikt og en så attraktiv informasjonstjeneste? Først av alt gir det et hypermedia-grensesnitt til data. Tenk på datamaskinens harddisk. Vanligvis uttrykkes data på en lineær måte, som ligner på et filsystem. For eksempel har du en rekke mapper, og inne i hver mappe er det enten dokumenter eller andre mapper. Nettet bruker et annet paradigme for å uttrykke informasjon kalt hypermedia. Et hypertekstgrensesnitt består av et dokument og lenker. Lenker er ord som klikkes for å se andre dokumenter eller finne andre typer informasjon. Nettet utvider konseptet hypertekst til å omfatte andre typer medier, som grafikk, lyder, video (derav navnet "hypermedia"). Ved å velge tekst eller grafikk på et dokument kan du se relatert informasjon om det valgte elementet i et hvilket som helst antall former.

Nesten alle kan dra nytte av denne enkle og unike måten å presentere og distribuere informasjon på, fra akademikere som umiddelbart ønsker å bruke data med sine kolleger til forretningsfolk som deler informasjon om bedriften sin med alle. Men selv om det å gi informasjon er ekstremt viktig, har mange de siste årene følt at det å motta informasjon er en like viktig prosess.

Selv om nettet gir et unikt hypermedia-grensesnitt for informasjon, er det mange andre effektive måter å distribuere data på. For eksempel eksisterte nettverkstjenester som File Transfer Protocol (FTP) og Gopher-nyhetsgruppen lenge før World Wide Web. Elektronisk post har vært det primære mediet for kommunikasjon og informasjonsutveksling på Internett og de fleste andre nettverk nesten helt fra begynnelsen av disse nettverkene. Hvorfor har Internett blitt en så populær måte å distribuere informasjon på? Multimediaaspektet ved Internett har bidratt betydelig til dets enestående suksess, men for at Internett skal være mest effektivt, må det være interaktivt.

Uten muligheten til å motta brukerinndata og gi informasjon, ville nettet vært et fullstendig statisk miljø. Informasjonen vil kun være tilgjengelig i formatet spesifisert av forfatteren. Dette ville undergrave en av egenskapene til databehandling generelt: interaktiv informasjon. For eksempel, i stedet for å tvinge brukeren til å se flere dokumenter som om han eller hun ser gjennom en bok eller ordbok, ville det være bedre å la brukeren identifisere nøkkelord om et emne av interesse. Brukere kan tilpasse presentasjonen av data i stedet for å stole på en rigid struktur definert av innholdsleverandøren.

Begrepet "webserver" kan være misvisende fordi det kan referere til både den fysiske maskinen og programvaren den bruker for å kommunisere med nettlesere. Når en nettleser ber om en gitt webadresse, kobles den først til maskinen via Internett, og sender webserverprogramvaren en forespørsel om dokumentet. Denne programvaren kjører kontinuerlig, venter på at slike forespørsler kommer og svarer deretter.

Selv om servere kan sende og motta data, har selve serveren begrenset funksjonalitet. For eksempel kan den mest primitive serveren bare sende den nødvendige filen til nettleseren. Serveren vet vanligvis ikke hva den skal gjøre med denne eller den ekstra inngangen. Hvis Internett-leverandøren ikke forteller serveren hvordan denne tilleggsinformasjonen skal håndteres, vil serveren mest sannsynlig ignorere inndataene.

For at serveren skal kunne utføre andre operasjoner i tillegg til å søke og sende filer til nettleseren, må du vite hvordan du utvider funksjonaliteten til serveren. En webserver kan for eksempel ikke søke i en database basert på et nøkkelord angitt av en bruker og returnere flere samsvarende dokumenter med mindre en slik funksjon er programmert inn i serveren på en eller annen måte.

Hva er CGI?

Common Gateway Interface (CGI) er et grensesnitt til serveren som lar deg utvide funksjonaliteten til serveren. Ved å bruke CGI kan du interagere interaktivt med brukere som har tilgang til nettstedet ditt. På et teoretisk nivå lar CGI serveren kunne parse (tolke) input fra nettleseren og returnere informasjon basert på brukerens input. På et praktisk nivå er CGI et grensesnitt som lar en programmerer skrive programmer som enkelt kommuniserer med en server.

Vanligvis, for å utvide serverens muligheter, må du endre serveren selv. Denne løsningen er uønsket fordi den krever forståelse for det nedre laget av Internett-protokollnettverksprogrammering. Dette vil også kreve redigering og rekompilering av serverkildekoden eller skriving av en tilpasset server for hver oppgave. La oss si at du vil utvide serverens muligheter slik at den fungerer som en nett-til-e-post-gateway, som tar brukerangitt informasjon fra nettleseren og sender den til en annen bruker. Serveren må sette inn kode for å analysere inngangen fra nettleseren, videresende den via e-post til den andre brukeren og videresende svaret tilbake til nettleseren over nettverkstilkoblingen.

For det første krever en slik oppgave tilgang til serverkoden, noe som ikke alltid er mulig.

For det andre er det vanskelig og krever omfattende teknisk kunnskap.

For det tredje gjelder dette bare en bestemt server. Hvis du trenger å flytte serveren til en annen plattform, må du kjøre eller i det minste bruke mye tid på å portere kode til den plattformen.

Hvorfor CGI?

CGI tilbyr en bærbar og enkel løsning på disse problemene. CGI-protokollen definerer en standard måte for programmer å kommunisere med en webserver. Uten noen spesiell kunnskap kan du skrive et program på et hvilket som helst maskinspråk som grensesnitt og kommuniserer med webserveren. Dette programmet vil fungere med alle webservere som forstår CGI-protokollen.

CGI-kommunikasjon gjøres ved å bruke standard input og output, noe som betyr at hvis du vet hvordan du skriver ut og leser data ved å bruke programmeringsspråket ditt, kan du skrive en webserverapplikasjon. Bortsett fra å analysere input og output, er programmering av CGI-applikasjoner nesten tilsvarende å programmere alle andre applikasjoner. For å programmere "Hello, World!"-programmet for eksempel, bruker du språkets utskriftsfunksjoner og formatet som er definert for CGI-programmer for å skrive ut den aktuelle meldingen.

Velge et programmeringsspråk

Fordi CGI er et universelt grensesnitt, er du ikke begrenset til noe spesifikt maskinspråk. Et viktig spørsmål som ofte stilles er: hvilke programmeringsspråk kan brukes til CGI-programmering? Du kan bruke et hvilket som helst språk som lar deg gjøre følgende:

• Skriv ut til standard utskrift
• Les fra standard input
• Les fra variable moduser

Nesten alle programmeringsspråk og mange skriptspråk gjør disse tre tingene, og du kan bruke hvilken som helst av dem.

Språk faller inn i en av følgende to klasser: oversatt og tolket. Et oversatt språk som C eller C++ er vanligvis mindre og raskere, mens tolkede språk som Perl eller Rexx noen ganger krever at en stor tolk lastes ved oppstart. I tillegg kan du distribuere binære koder (kode som oversettes til maskinspråk) uten kildekode hvis språket ditt er oversettbart. Å distribuere tolkbare skript betyr vanligvis å distribuere kildekode.

Før du velger språk, må du først vurdere prioriteringene dine. Du må veie fordelene med hastigheten og effektiviteten til ett programmeringsspråk opp mot programmeringsvennligheten til et annet. Hvis du har et ønske om å lære et annet språk, i stedet for å bruke det du allerede kan, vei nøye fordelene og ulempene med begge språkene.

De to mest brukte språkene for CGI-programmering er C og Perl (som begge er dekket i denne boken). Begge har klare fordeler og ulemper. Perl er et språk på meget høyt nivå, og samtidig et kraftig språk, spesielt egnet for å analysere tekst. Selv om dens brukervennlighet, fleksibilitet og kraft gjør det til et attraktivt språk for CGI-programmering, gjør dens relativt store størrelse og langsommere drift det noen ganger uegnet for noen applikasjoner. C-programmer er mindre, mer effektive og gir systemkontroll på lavere nivå, men er mer komplekse å programmere, har ikke lette innebygde tekstbehandlingsrutiner og er vanskeligere å feilsøke.

Hvilket språk er best egnet for CGI-programmering? Den som du anser som mer praktisk fra et programmeringssynspunkt. Begge er like effektive for programmering av CGI-applikasjoner, og med de riktige bibliotekene har begge lignende funksjoner. Men hvis du har en vanskelig tilgjengelig server, kan du bruke mindre, oversatte C-programmer. Skal du raskt skrive en applikasjon som krever mye tekstbehandlingsarbeid, kan du bruke Perl i stedet.

Advarsler

Det er noen viktige alternativer til CGI-applikasjoner. Mange servere inkluderer nå API-programmering, som gjør det enklere å programmere direkte serverutvidelser i motsetning til frittstående CGI-applikasjoner. API-servere er generelt mer effektive enn CGI-programmer. Andre servere inkluderer innebygd funksjonalitet som kan håndtere spesielle ikke-CGI-elementer, for eksempel databasekobling. Til slutt kan noen applikasjoner håndteres av noen nye klient-side (i stedet for server-side) teknologier som Java. Med så raske endringer i teknologi, vil CGI raskt bli foreldet?

Neppe. CGI har flere fordeler i forhold til nyere teknologier.

• Den er allsidig og bærbar. Du kan skrive en CGI-applikasjon ved å bruke nesten alle programmeringsspråk på hvilken som helst plattform. Noen av alternativene, som server-API, begrenser deg til visse språk og er mye vanskeligere å lære.
• Det er lite sannsynlig at klientsideteknologier som Java vil erstatte CGI, fordi det er noen applikasjoner som serversideapplikasjoner er mye bedre egnet til å kjøre.
• Mange av begrensningene til CGI er begrensninger for HTML eller HTTP. Ettersom Internett-standarder som helhet utvikler seg, utvikler CGI-funksjonene seg også.

Sammendrag

Common Gateway Interface er protokollen som programmer samhandler med webservere med. Allsidigheten til CGI gir programmerere muligheten til å skrive gateway-programmer på nesten alle språk, selv om det er mange avveininger knyttet til forskjellige språk. Uten denne muligheten ville det være vanskelig å lage interaktive nettsider, i beste fall kreve servermodifikasjoner, og interaktivitet ville være utilgjengelig for de fleste brukere som ikke er nettstedadministratorer.

Kapittel 2: Grunnleggende

For flere år siden opprettet jeg en side for en høyskole ved Harvard der folk kunne sende inn kommentarer om dem. På den tiden var Internett ungt og dokumentasjon var knapp. Jeg, som mange andre, stolte på kort dokumentasjon og programmeringssystemer laget av andre for å lære meg selv CGI-programmering. Selv om denne studiemetoden krevde litt søking, mange eksperimenter og skapte mange spørsmål, var den veldig effektiv. Dette kapittelet er resultatet av mitt tidlige arbeid med CGI (med noen få justeringer, selvfølgelig).

Selv om det tar litt tid å forstå og mestre det vanlige gateway-grensesnittet, er selve protokollen ganske enkel. Alle som har noen grunnleggende programmeringskunnskaper og er kjent med nettet kan raskt lære å programmere ganske komplekse CGI-applikasjoner akkurat som jeg og andre lærte å gjøre for flere år siden.

Formålet med dette kapittelet er å presentere det grunnleggende om CGI på en omfattende, om enn fortettet måte. Hvert konsept som diskuteres her presenteres i detalj i påfølgende kapitler. Men etter å ha fullført dette kapittelet, kan du umiddelbart begynne å programmere CGI-applikasjoner. Når du har nådd dette nivået, kan du lære detaljene med CGI, enten ved å lese resten av denne boken eller ganske enkelt eksperimentere på egen hånd.

Du kan koke ned CGI-programmering til to oppgaver: motta informasjon fra nettleseren og sende informasjon tilbake til nettleseren. Dette gjøres ganske intuitivt når du blir kjent med normal bruk av CGI-applikasjoner. Ofte blir brukeren bedt om å fylle ut et skjema, for eksempel sette inn navnet sitt. Når brukeren fyller ut skjemaet og trykker Enter, sendes denne informasjonen til CGI-programmet. CGI-programmet må da konvertere denne informasjonen til noe den forstår, behandle den deretter, og deretter sende den tilbake til nettleseren, enten det er en enkel bekreftelse eller et resultat av et søk i en flerbruksdatabase.

Med andre ord krever programmering av CGI å forstå hvordan man mottar input fra nettleseren og hvordan man sender utdata tilbake. Hva som skjer mellom input- og output-stadiene til et CGI-program avhenger av utviklerens mål. Du vil finne at hovedvanskeligheten i CGI-programmering ligger i dette mellomstadiet; Når du først har lært å jobbe med input og output, er det egentlig nok til å bli en CGI-utvikler.

I dette kapittelet lærer du prinsippene bak CGI-inndata og -utdata, samt andre grunnleggende ferdigheter du trenger for å skrive og bruke CGI, inkludert ting som å lage HTML-skjemaer og navngi CGI-programmene dine. Dette kapittelet dekker følgende emner:

• Tradisjonelt program "Hei, verden!";
• CGI Output: Sender informasjon tilbake for visning i en nettleser;
• Konfigurere, installere og kjøre programmet. Du vil lære om ulike nettplattformer og servere;
• CGI-inngang: Tolkning av informasjon sendt av nettleseren. Introduksjon til noen nyttige programmeringsbiblioteker for å analysere slike input;
• Et enkelt eksempel: det dekker alle leksjonene i et gitt kapittel;
• Programmeringsstrategi.

På grunn av dette kapitlets natur berører jeg bare noen emner. Ikke bekymre deg; Alle disse emnene dekkes mye mer i dybden i andre kapitler.

Hei Verden!

Du starter med et tradisjonelt innledende programmeringsproblem. Du skal skrive et program som viser "Hello, World!" på nettleseren din. Før du skriver dette programmet, må du forstå hvilken informasjon nettleseren forventer å motta fra CGI-programmer. Du må også vite hvordan du kjører dette programmet slik at du kan se det i aksjon.

CGI er språkuavhengig, så du kan implementere dette programmet på alle språk. Flere forskjellige språk brukes her for å demonstrere uavhengigheten til hvert språk. I Perl, "Hello, World!"-programmet vist i oppføring 2.1.

Oppføring 2.1. Hei Verden! i Perl. #!/usr/local/bin/perl # Hello.cgi - Min første CGI-programutskrift "Content-Type: text/html\n\n"; skrive ut " \n"; skriv ut " "; skrive ut "\n"; skriv ut " \n"; skriv ut "

Hei Verden!

Lagre dette programmet som hello.cgi, og installer det på riktig sted. (Hvis du ikke er sikker på hvor det er, ikke bekymre deg; du vil finne ut av det i delen "Installere og kjøre et CGI-program" senere i dette kapittelet.) For de fleste servere er katalogen du trenger cgi-bin . Ring nå programmet fra nettleseren din. For de fleste betyr dette å åpne følgende enhetlige ressurslokalisator (URL):

http://vertsnavn/katalognavn/hello.cgi

Vertsnavn er navnet på webserveren din, og katalognavn er katalogen der du legger hello.cgi (sannsynligvis cgi-bin).

Splitting hello.cgi

Det er et par ting å merke seg om hello.cgi.

Først bruker du enkle utskriftskommandoer. CGI-programmer krever ingen spesielle filbeskrivelser eller utdatabeskrivelser. For å sende utdata til nettleseren, bare skriv ut til stdout.

For det andre, merk at innholdet i den første utskriftserklæringen (Content-Type: text/html) ikke vises i nettleseren din. Du kan sende all informasjon du vil tilbake til nettleseren (HTML-side, grafikk eller lyd), men først må du fortelle nettleseren hva slags data du sender den. Denne linjen forteller nettleseren hva slags informasjon du kan forvente - i dette tilfellet en HTML-side.

For det tredje heter programmet hello.cgi. Du trenger ikke alltid å bruke .cgi-utvidelsen med navnet på CGI-programmet. Selv om kildekoden for mange språk også bruker filtypen .cgi, brukes den ikke til å angi språktypen, men er en måte for serveren å identifisere filen som en kjørbar fil i stedet for en grafikkfil, HTML-fil eller tekstfil. Servere er ofte konfigurert til å bare forsøke å kjøre de filene som har denne utvidelsen, og viser innholdet til alle andre. Selv om det ikke er nødvendig å bruke .cgi-utvidelsen, anses det fortsatt som god praksis.

Generelt består hello.cgi av to hoveddeler:

• forteller nettleseren hvilken informasjon de kan forvente (Innholdstype: text/html)
• forteller nettleseren hva den skal vise (Hei, verden!)

Hei Verden! i C

For å vise språkuavhengigheten til CGI-programmer, viser Listing 2.2 ekvivalenten til hello.cgi-programmet skrevet i C.

Oppføring 2.2. Hei Verden! i C. /* hello.cgi.c - Hei, World CGI */ #include int main() ( printf("Innholdstype: text/html\r\n\r\n"); printf(" \n"); printf(" \n"); printf("\n"); printf(" \n"); printf("

Hei Verden!

Merk

Merk at Perl-versjonen av hello.cgi bruker Content-Type print ": text/html\n\n "; Mens versjon C bruker Printf("Content-Type: text/html\r\n\r\n");

Hvorfor skriver Perl ut operatøren med to nye linjer (\n) mens C printf slutter med to vognretur og nye linjer (\r\n)?

Teknisk sett forventes overskrifter (alle utdata før den tomme linjen) å være atskilt med vognretur og nye linjer. Dessverre, på DOS- og Windows-maskiner, oversetter Perl \r som en ny linje i stedet for som en vognretur.

Selv om Perls unntak er teknisk feil, vil det fungere på nesten alle protokoller og er like bærbart på tvers av alle plattformer. Derfor, i alle Perl-eksemplene i denne boken, bruker jeg linjeseparerende overskrifter i stedet for vognretur og linjeskift.

En passende løsning på dette problemet er presentert i kapittel 4, konklusjon.

Verken webserveren eller nettleseren bryr seg om hvilket språk som brukes til å skrive programmet. Selv om hvert språk har fordeler og ulemper som et CGI-programmeringsspråk, er det best å bruke det språket du er mest komfortabel med å jobbe med. (Valget av programmeringsspråk er diskutert mer detaljert i kapittel 1, "Common Gateway Interface (CGI)").

CGI-gjengivelse

Nå kan du se nærmere på problemet med å sende informasjon til nettleseren. Fra "Hello, World!"-eksemplet kan du se at nettlesere forventer to sett med data: en header, som inneholder informasjon som hvilken informasjon som skal vises (f.eks. Content-Type: line) og faktisk informasjon (hva nettleseren skjermer). Disse to opplysningene er atskilt med en tom linje.

Overskriften kalles HTTP-overskriften. Den gir viktig informasjon om informasjonen som nettleseren skal motta. Det finnes flere forskjellige typer HTTP-headere, og den vanligste er den du har brukt før: Content-Type: header. Du kan bruke forskjellige kombinasjoner av HTTP-hoder, atskilt med vognretur og nylinjer (\r\n). Den tomme linjen som skiller overskriften fra dataene består også av en vognretur og en ny linje (hvorfor begge er nødvendig er kort diskutert i det foregående notatet og detaljert i kapittel 4). Du vil lære om andre HTTP-hoder i kapittel 4; For øyeblikket har du å gjøre med Content-Type: header.

Content-Type: Overskriften beskriver typen data som CGI returnerer. Det riktige formatet for denne overskriften er:

Innholdstype: undertype/type

Der undertype/type er den riktige typen Multipurpose Internet Mail Extensions (MIME). Den vanligste MIME-typen er HTML-typen: text/html. Tabell 2.1 viser noen flere vanlige MIME-typer som vil bli diskutert; En mer fullstendig liste og analyse av MIME-typer er gitt i kapittel 4.

Merk

MIME ble opprinnelig oppfunnet for å beskrive innholdet i e-postmeldinger. Det har blitt en ganske vanlig måte å representere informasjon av innholdstype. Du kan lese mer om MIME i RFC1521. RFC-er på Internett står for Requests for Comments, som er sammendrag av beslutninger tatt av grupper på Internett som prøver å sette standarder. Du kan se resultatene av RFC1521 på følgende adresse: http://andrew2.andrew.cmu.edu/rfc/rfc1521.html

Tabell 2.1. Noen vanlige MIME-typer. MIME-type Beskrivelse Tekst/html Hypertekst Markup Language (HTML) Tekst/ren tekstfiler Bilde/gif Grafikkfiler GIF Bilde/jpeg Komprimerte grafikkfiler JPEG-lyd/grunnleggende lydfiler Sun *.au Audio/x-wav Windows-filer *. wav

Etter overskriften og en tom linje skriver du ganske enkelt ut dataene i skjemaet du trenger. Hvis du sender HTML, skriv ut HTML-taggene og dataene til stdout etter overskriften. Du kan også sende grafikk, lyd og andre binære filer ved ganske enkelt å skrive ut innholdet i filen til stdout. Det er gitt flere eksempler på dette i kapittel 4.

Installere og kjøre et CGI-program

Denne delen avviker noe fra CGI-programmering og snakker om å konfigurere webserveren til å bruke CGI, installere og kjøre programmer. Du vil bli introdusert til forskjellige servere for forskjellige plattformer mer eller mindre detaljert, men du må grave dypere i serverens dokumentasjon for å finne det beste alternativet.

Alle servere krever plass til serverfiler og plass til HTML-dokumenter. I denne boken heter serverområdet ServerRoot, og dokumentområdet heter DocumentRoot. På UNIX-maskiner er ServerRoot vanligvis i /usr/local/etc/httpd/, og DocumentRoot er vanligvis i /usr/local/etc/httpd/htdocs/. Dette vil imidlertid ikke utgjøre noen forskjell for systemet ditt, så bytt ut alle referanser til ServerRoot og DocumentRoot med din egen ServerRoot og DocumentRoot.

Når du får tilgang til filer ved hjelp av nettleseren, spesifiserer du filen i URL-en i forhold til DocumentRoot. For eksempel, hvis serveradressen din er mymachine.org, får du tilgang til denne filen med følgende URL: http://mymachine.org/index.html

Konfigurere serveren for CGI

De fleste webservere er forhåndskonfigurert for å tillate bruk av CGI-programmer. Vanligvis indikerer to parametere for serveren om filen er en CGI-applikasjon eller ikke:

• Utpekt katalog. Noen servere lar deg bestemme at alle filene i en utpekt katalog (vanligvis kalt cgi-bin som standard) er CGI.
• Filnavnutvidelser. Mange servere har denne forhåndskonfigurasjonen som gjør at alle filer som slutter på .cgi kan defineres som CGI.

Den utpekte katalogmetoden er noe av en relikvie fra fortiden (de aller første serverne brukte den som den eneste metoden for å avgjøre hvilke filer som var CGI-programmer), men den har flere fordeler.

• Det holder CGI-programmer sentralisert, og forhindrer at andre kataloger blir rotete.
• Du er ikke begrenset til noen bestemt filtype, så du kan navngi filene dine hva du vil. Noen servere lar deg angi flere forskjellige kataloger som CGI-kataloger.
• Det gir deg også mer kontroll over hvem som kan ta opp CGI. For eksempel, hvis du har en server og støtter et system med flere brukere og ikke vil at de skal bruke sine egne CGI-skript uten først å ha gjennomgått programmet av sikkerhetsgrunner, kan du angi bare disse filene i en begrenset, sentralisert katalog som CGI . Brukere må da gi deg CGI-programmer for å installere, og du kan først revidere koden for å sikre at programmet ikke har noen store sikkerhetsproblemer.

CGI-notasjonen via filtypen kan være nyttig på grunn av dens fleksibilitet. Du er ikke begrenset til én enkelt katalog for CGI-programmer. De fleste servere kan konfigureres til å gjenkjenne CGI via filtypen, selv om ikke alle er konfigurert på denne måten som standard.

Advarsel

Husk viktigheten av sikkerhetsproblemer når du konfigurerer serveren din for CGI. Noen tips vil bli dekket her, og kapittel 9, Protecting CGI, dekker disse aspektene mer detaljert.

Installere CGI på UNIX-servere

Uansett hvordan UNIX-serveren din er konfigurert, er det flere trinn du må ta for å sikre at CGI-applikasjonene kjører som forventet. Webserveren din vil vanligvis kjøre som en ikke-eksisterende bruker (det vil si UNIX-brukeren ingen - en konto som ikke har filrettigheter og ikke kan logges på). CGI-skript (skrevet i Perl, Bourne-skallet eller et annet skriptspråk) må være kjørbare og lesbare over hele verden.

Clue

For å gjøre filene dine verdenslesbare og kjørbare, bruk følgende UNIX-tillatelseskommando: chmod 755 filnavn.

Hvis du bruker et skriptspråk som Perl eller Tcl, oppgi hele banen til tolken din på den første linjen i skriptet. For eksempel vil et Perl-skript som bruker perl i /usr/local/bin-katalogen begynne med følgende linje:

#!/usr/local/bin/perl

Advarsel

Plasser aldri tolken (perl, eller Tcl Wish binær) i /cgi-bin-katalogen. Dette skaper en sikkerhetsrisiko på systemet ditt. Dette diskuteres mer detaljert i kapittel 9.

Noen generiske UNIX-servere

NCSA- og Apache-serverne har lignende konfigurasjonsfiler fordi Apache-serveren opprinnelig var basert på NCSA-koden. Som standard er de konfigurert slik at enhver fil i cgi-bin-katalogen (som ligger som standard i ServerRoot) er et CGI-program. For å endre plasseringen av cgi-bin-katalogen, kan du redigere konfigurasjonsfilen conf/srm.conf. Formatet for å konfigurere denne katalogen er

ScriptAlias ​​​​fakedirectoryname realdirectoryname

der fakedirectoryname er pseudokatalognavnet (/cgi-bin) og realdirectoryname er hele banen der CGI-programmene faktisk er lagret. Du kan konfigurere mer enn ett ScriptAlias ​​ved å legge til flere ScriptAlias-linjer.

Standardkonfigurasjonen er tilstrekkelig for de fleste brukeres behov. Du må redigere linjen i srm.conf-filen i begge tilfeller for å finne riktig realdirectoryname. Hvis for eksempel CGI-programmene dine er plassert i /usr/local/etc/httpd/cgi-bin, skal ScriptAlias-linjen i srm.conf-filen din være omtrent slik:

ScriptAlias ​​​​/cgi-bin/ /usr/local/etc/httpd/cgi-bin/

For å få tilgang til eller koble til CGI-programmer i denne katalogen, bruk følgende URL:

Http://vertsnavn/cgi-bin/programnavn

Der vertsnavn er navnet på verten til webserveren din, og programnavn er navnet på CGI-en din.

La oss for eksempel si at du kopierer hello.cgi-programmet til cgi-bin-katalogen din (f.eks. /usr/local/etc/httpd/cgi-bin) på webserveren din kalt www.company.com. For å få tilgang til din CGI, bruk følgende URL: http://www.company.com/cgi-bin/hello.cgi

Hvis du vil konfigurere NCSA- eller Apache-serveren til å gjenkjenne en fil med en .cgi-utvidelse som en CGI, må du redigere to konfigurasjonsfiler. Først, i srm.conf-filen, fjerner du følgende linje:

AddType application/x-httpd-cgi .cgi

Dette vil knytte MIME-typen CGI til .cgi-utvidelsen. Nå må vi endre filen access.conf slik at vi kan kjøre CGI i hvilken som helst katalog. For å gjøre dette, legg til ExecCGI-alternativet på Option-linjen. Det vil se omtrent ut som følgende linje:

Opsjonsindekser FollowSymLinks ExecCGI

Nå regnes enhver fil med filtypen .cgi som CGI; få tilgang til den som en hvilken som helst fil på serveren din.

CERN-serveren er konfigurert på samme måte som Apache- og NCSA-servere. I stedet for ScriptAlias ​​bruker CERN-serveren Exec-kommandoen. For eksempel, i httpd.conf-filen vil du se følgende linje:

Exec /cgi-bin/* /usr/local/etc/httpd/cgi-bin/*

Andre UNIX-servere kan konfigureres på samme måte; Dette er beskrevet mer detaljert i serverdokumentasjonen.

Installere CGI på Windows

De fleste servere som er tilgjengelige for Windows 3.1, Windows 95 og Windows NT er konfigurert ved hjelp av "filnavnsutvidelse"-metoden for CGI-gjenkjenning. Generelt krever endring av konfigurasjonen til en Windows-basert server ganske enkelt å kjøre serverkonfigurasjonsprogrammet og gjøre de nødvendige endringene.

Noen ganger kan det være vanskelig å konfigurere en server til å kjøre et skript (som Perl) riktig. I DOS eller Windows vil du ikke kunne spesifisere tolken på den første linjen i skriptet, slik tilfellet er med UNIX. Noen servere har en forhåndsdefinert konfigurasjon for å knytte visse filnavn til tolken. For eksempel antar mange Windows-webservere at filer som slutter på .pl er Perl-skript.

Hvis serveren ikke utfører denne typen filtilknytning, kan du definere en pakkefil som kaller både tolken og skriptet. Som med UNIX-serveren, ikke installer tolken verken i cgi-bin-katalogen eller noen netttilgjengelig katalog.

Installere CGI på Macintosh

De to mest kjente serveralternativene for Macintosh er WebStar StarNine og forgjengeren MacHTTP. Begge gjenkjenner CGI ved filtypen.

MacHTTP forstår to forskjellige utvidelser: .cgi og .acgi, som står for asynkron CGI. Vanlige CGI-programmer installert på en Macintosh (med en .cgi-utvidelse) vil holde webserveren i en opptatt tilstand til CGI kjører ferdig, noe som får serveren til å suspendere alle andre forespørsler. Asynkron CGI, derimot, lar serveren godta forespørsler selv mens den kjører.

En CGI Macintosh-utvikler som bruker en av disse webserverne, bør, hvis mulig, bare bruke .acgi-utvidelsen i stedet for .cgi-utvidelsen. Det skal fungere med de fleste CGI-programmer; hvis det ikke fungerer, endre navn på programmet til .cgi.

Utfører CGI

Når du har installert CGI, er det flere måter å utføre den på. Hvis CGI-programmet ditt er et program med kun utdata, for eksempel Hello,World!-programmet, kan du kjøre det ganske enkelt ved å gå til URL-en.

De fleste programmer kjører som en serverapplikasjon på et HTML-skjema. Før du lærer hvordan du får informasjon fra disse skjemaene, bør du først lese en kort introduksjon om hvordan du lager slike skjemaer.

En rask veiledning om HTML-skjemaer

De to viktigste kodene i et HTML-skjema er Og . Du kan lage de fleste HTML-skjemaer ved å bruke bare disse to kodene. I dette kapittelet vil du utforske disse kodene og et lite undersett av mulige typer eller attributter. . En komplett veiledning og lenke til HTML-skjemaer er i kapittel 3, HTML og skjemaer.

stikkord

stikkord brukes til å bestemme hvilken del av HTML-filen som skal brukes for brukeroppgitt informasjon. Dette refererer til hvordan de fleste HTML-sider kaller et CGI-program. Tag-attributter spesifiserer programmets navn og plassering - enten lokalt eller som en fullstendig URL, typen koding som brukes, og dataoverføringsmetoden som brukes av programmet.

Den neste linjen viser spesifikasjonene for taggen :

< ACTION FORM = "url" METHOD = ENCTYPE = "..." >

ENCTYPE-attributtet spiller ingen spesiell rolle og er vanligvis ikke inkludert i taggen . Detaljert informasjon om ENCTYPE-taggen er gitt i kapittel 3. En måte å bruke ENCTYPE på er vist i kapittel 14, "Branded Extensions."

ACTION-attributtet refererer til URL-en til CGI-programmet. Når brukeren fyller ut skjemaet og gir informasjon, blir all informasjon kodet og overført til CGI-programmet. CGI-programmet løser selv problemet med dekoding og prosessering av informasjon; Dette aspektet er diskutert i "Godta inndata fra nettleseren," senere i dette kapittelet.

Til slutt beskriver METHOD-attributtet hvordan CGI-programmet skal motta input. De to metodene, GET og POST, er forskjellige i hvordan de sender informasjon til CGI-programmet. Begge er omtalt i "Godta inndata fra nettleseren."

For at nettleseren skal tillate brukerinndata, må alle skjematagger og informasjon være omgitt av taggen . Ikke glem den avsluttende taggen

Skriv inn alderen din: