Serverillä on useakin palanen, joka määrää kuinka suuria tiedostoja saa siirtää. Webserveri, Apache2 tai Nginx yleisimpinä, asettavat omat rajansa. PHP:n säädöt lienevät kaikille tuttuja. Itselläni on ensimmäisenä Nginx hoitamassa SSL:n ja hyväksymässä HTTP/2-liikenteen, eikä tee sen jälkeen mitään muuta, kuin kääntää kyselyt Varnishille. Varnish tarjoaa sisällön joko omasta cachestaan tai käy pyytämässä tuoreempaa saalista Apachelta. Kun latauksissa, siirroissa tai oikeastaan missä tahansa tulee virhe, niin ensimmäiseksi pitäisi kyetä arvaamaan missä on vika – eikä se ole aina niin selvää. Ainakaan minulle.

Minulla lakkasi yhtä äkkiä podcastien MP3-tiedostot toimimasta. Samaan aikaan niiden lataaminen WordPressiin kaatui mystiseen ilmoitukseen, että serveri oli vastannut omituisesti. Lisäksi kuvan siirrossa WordPressin mediakirjasto loihe lausumaan, että kuvia käsittelevä EWWW ei pysty työstämään suoraan kamerasta ladattua kuvaani. Olin ihmeissäni missä mennään. Kokeilin muita samalla serverillä olevia sivustojani, ja kaikilla oli sama ongelma. Kun myöskään Moodle ei kyennyt tekemään pyydettyjä siirtoja, niin yksi asia oli selvä: ongelma on jossain kohtaa kolmikkoa Nginx – Varnish – Apache2. Google ei tuonut apua, ja jätin ongelman muhimaan kiertäen MP3-latauksen linkittämällä sen Amazonin S3-bucketista; edelleen vanhat podcastit olivat toimimattomia.

Joskus kannattaa nukkua yön yli, varsinkin kun vika on enemmän kiusallinen kuin kriittinen. Kaikki muu kuitenkin toimi ja kävijän näkökulmasta podcastit eivät toimineet. Tosin aamukaan ei tuonut apua ja kun olin työpäivän verran mennyt asetuksia läpi ja kiusannut Googlea tulematta hullua hurskaammaksi, luovutin hetkeksi. Siirryin asettamaan työn alla ollutta täysin tuoretta Woocommerce-kauppaa.

Siirsin käytettäväksi suunniteltua teemaa ja muutama prosentti ennen latauksen vamistumista sain virheilmoituksen, jonka omisti Nginx:

413 Request Entity Too Large

Google antoi nopeasti vastauksen. Siirrettävä tiedosto oli liian suuri. Jos kokorajaa ei ole erikseen asetettu, niin raja on huimaava yksi mega (samaa alimitoitusta kuin PHP:n asetuksissa; oikeasti, kuka näitä oikein keksii). Koska rajaa ei ole oletuksena Nginxin asetuksissa, niin en ollut edes osannut kaivata sitä. Saatika ajatella. koska minun näkemykseni mukaan Nginx ei tehnyt mitään muuta kuin päästi pyynnöt proxylle ja työn tekivät Varnish ja Apache2.

Tuo on helppo korjata.

nano /etc/nginx/nginx.conf

Halun mukaan laitat lohkoon http, server tai location tämän:

client_max_body_size 0;

• arvo 0 kieltää Nginxiä puuttumasta tiedostokokoihin. Minulle riittää, että sitä rajoittavat WordPress ja Moodle omassa toiminnassaan sekä aidosti virtual hostien tasolla PHP ja Apache2
• voit laittaa siihen haluamasi koon, esimerkiksi 5 M, 100M tai mitä halajatkaan

Itse laitoin tuon blokkiin http ja ainoa syy oli, että halusin sen taatusti serverille ”globaaliksi” (eikä minulla ole nginx.conf tiedostossa muita lohkoja).

Asetus korjasi ongelmat. Yhtä äkkiä serveri ei antanutkaan WordPressille ymmärtämättömiä vastauksia, vaan MP3-tiedostot siirtyivät iloisesti. EWWW kykenikin aivan yhtä äkkiä käsittelemään 5 megan kuvia. Se, että olin luullut serverin tarkoittavan sitä serveriä, joka tekee työtä WordPressin kanssa, vaikka aidosti kyse oli vain siitä kaverista, joka hyväksyi https-osoitteet, maksoi minulle noin 16 tunnin edestä turhaa työtä ja tekemätöntä hyödyllistä duunia.

Se, että miksi törmäsin tuohon vasta nyt. on hieman mysteeri. Selitys lienee niin yksinkertainen, että siirrän aika harvoin kuvia puhelimen originaalikoossa, ja olin tehnyt podcastiksi normaalia lähes tuplan pidemmän äänityksen. Ehkä en vain ollut aiemmin rikkonut 1M rajaa.

Podcastit eivät lähteneet tuolla toimimaan. Siihen löytyi ihan oma ongelmansa. Poistin CDN:n käytöstä turhana ja liian kalliina. WordPressissä käyttämäni WP Offload Media osasi kyllä laittaa joka paikkaan CDN:n vaatimat urlit, mutta ei osannut poistaa niitä joka paikasta. Kun laitoin (käsin) jokaiseen podcast-postaukseen paikallisen urlin MP3-tiedostoon CDN-osoitteen sijaan, niin nekin lähtivät toimimaan.