miniserv lähti liikkeelle aivan pienestä kokeilusta. Tein Noden päälle suurinpiirtein “hello worldia” vastaavan tason serverin. Serveri on siis JavaScript-koodia, ja se ajetaan käyntiin nodella.

Aloitustilanne miniserv.js – lähdekoodin laajuus

C:\nodestas>sloc miniserv.js

---------- Result ------------

            Physical :  35
              Source :  18
             Comment :  13
 Single-line comment :  13
       Block comment :  0
               Mixed :  1
 Empty block comment :  0
               Empty :  5
               To Do :  0

Number of files read :  1

----------------------------

Seuraavaksi laajennan tätä, niin että serveri osaa tarjoilla yhden hakemiston sisältöineen, eli tiedostoineen.

Tässä vaiheessa siis tulee jo luultavasti hieman ensimmäisiä harkintaa vaativia asioita.

Muutokset (lisäykset) serverin logiikassa:

• palvelimen käsittelemä (web-selaimelta tuleva) GET -request saa nyt parametrikseen joko “/” tai tiedostonimen
• serverin pitää päättää, onko GET perässä tuleva parametri sallittu (jolloin serveri tarjoilee kysytyn tiedoston), vai johtaako parametri pimentoon (tiedostoa ei löydy, tai pääsy on kielletty, tai parametri ei sovellu tiedoston nimeksi)
• jos GET pyytämä tiedosto oli o.k., annetaan 200 OK ja palautetaan tiedoston sisältö (mahdollisesti jotenkin puskuroituna, todennäköisesti Node hoitaa tämän peltien alla automaattisesti)
• jos syntyi virhe, annetaan sopiva HTTP virhekoodi (lista Wikipediassa)

Lyhyt recap vielä miten ylläoleva muuttaa tilannetta; ennen muutosta, nykyinen v0.1.0 serveri vain odottaa portissa 8000 selaimen kutsua ja palauttaa staattisen merkkijonon, joka on serverin “allekirjoitus” (signature). Ideana on siis todeta, että “moi, olen elossa, tässä on allekirjoitukseni”.

Uusi ominaisuus: tarjoillaan tiedosto

Nyt serveriä laajennetaan ymmärtämään tiedoston pyyntö. Oikeissa web-servereissä puhutaan reiteistä (‘routing‘). Käytännössä teen nyt miniserv :iin pelkän 1:1 staattisen vastaavuuden resurssin nimen ja serverillä olevan tiedoston nimen välillä. Eli jos käyttäjä antaa URLin:

http://servu.mme:8000/koe.txt 

serveri saa pyynnön “GET /koe.txt”. Tästä serverin koodi eristää vain loppuosan (kaikki ‘/’ merkin jälkeen aina rivin loppuun saakka), ja tarkistaa 2 asiaa: että kyseinen tiedostonimi ei sisällä konnankoukkuja, ja että pyyntöä vastaava tiedosto on olemassa myös serverillä. Jos molemmat ehdot o.k., niin serveri palauttaa tiedoston sisällön.

Kolmen rivin markkinointipuhe ominaisuuksista

• serveri tarjoilee yhden hakemiston (folder) sisältöineen
• serveri antaa oikeat HTTP tilakoodit tilanteen mukaan
• ajokomento on ‘node ./miniserv.js –serve=hakemisto’
• ei pääsynvalvontaa, joten tiedostot on kaikille näkyvissä jotka tietävät serveristä

Mihin miniserv soveltuisi tässä vaiheessa?

Nodeahan ja sorminäppäryyttä tässä edelleen opiskellaan. Silti ihan oikeakin käyttötapaus serverille voisi olla: haluat jakaa väliaikaisesti hakemiston sisältöineen webin kautta. Joskus voi olla tarve vain nopeasti kopioida tiedostot jonnekin jakoon.

Huom! Tällaisenään serveri ei esimerkiksi mitenkään toteuta pääsynvalvontaa, eli: kuka tahansa, joka sattuu löytämään serverin julkisen IP-osoitteen ja arvaa käytetyn TCP-portin, näkee jakamasi tiedostot (kunnes pysäytät serverin, näppäinyhdistelmä Ctrl-C konsolissa – tai esimerkiksi prosessin tappamalla, ‘kill’-komennolla).

Serverin lupaus resurssin nimen pysyvyydestä

Mietin tätä versiota tehdessä, miten oikeastaan web-serveri tietää, mitä client tarkoittaa antamallaan polulla? Onko request yksikäsitteinen? Vastaus on: riippuu aivan sopimuksesta. Clientin pitää ymmärtää web-serverin tarjoamien resurssien semantiikka. Käytännössä, jos kyseessä olisi perinteinen web-serveri, niin näinhän onkin: yleensä serverit ovat teknisinä alustoina, rakennuspalikoina, osana web-sivustoja. Serverit tallentavat tiedot (niin staattiset HTML-sivut, yksittäiset kuvat ja muut resurssit, kuin myös tarvittaessa dynaamiset sisällöt) – ja tarjoavat sivut HTTP-protokollaa käyttäen. Tällöin sivun rakentajan huolena on pitää referenssit oikeina ja osuvina. Serveri lupaa sivun tekijälle pitää kerran tallennetut tiedot aina samalla tunnisteella saatavina, eli jos web-sivulla oleva kuva on alunperin tallentunut osoitteeseen

niin web-serveri ei voi yksikantaan itse muuttaa enää kuvan osoitetta. Dynaamisen sisällön suhteen on sama idea, mutta tällöin serverillä on enemmän vapautta tehdä optimointia tai muutoksia sisäiseen tallennusmekanismiin, kunhan ulkoinen sopimus (ts. resurssin osoite) edelleen ylläpitää.

Sivut voi koodata käsinkin, mutta aika usein tässä käytetään myös jotain editoria tai ohjelmistoa, ja yksi syy on juuri viittauksissa esiintyvien virheiden vähentäminen kun sivujen tekijän ei tarvitse suoraan toimia “raakatasolla”.

Teknisesti requestien on oltava yksikäsitteisiä, muuten web-serveri ei toimisi deterministisesti, eli se ei oikeastaan olisi tietokoneohjelma.