035.2 Lecke 1
Tanúsítvány: |
Web Development Essentials |
---|---|
Verzió: |
1.0 |
Témakör: |
035 NodeJS szerverprogramozás |
Fejezet: |
035.2 NodeJS Express alapok |
Lecke: |
1/2 |
Bevezetés
Az Express.js vagy egyszerűen Express egy népszerű keretrendszer, amely a Node.js-en fut, és a webes alkalmazások klienseinek kéréseit kezelő HTTP-szerverek írására szolgál. Az Express számos módon támogatja a HTTP-n keresztül küldött paraméterek olvasását.
Induló szerver szkript
Az Express alapvető funkcióinak bemutatásához, a kérések fogadásához és kezeléséhez szimuláljunk egy alkalmazást, amely információt kér a szervertől. A példaszerver konkrétan:
-
Biztosít egy
echo
függvényt, amely egyszerűen visszaadja a kliens által küldött üzenetet. -
Kérésre megadja a kliensnek az IP-címét.
-
Sütiket használ az ismert kliensek azonosítására.
Az első lépés a szerverként működő JavaScript-fájl létrehozása. Az npm
segítségével hozzunk létre egy myserver
nevű könyvtárat, benne a JavaScript-fájllal:
$ mkdir myserver $ cd myserver/ $ npm init
A belépési ponthoz bármilyen fájlnév használható. Itt az alapértelmezett fájlnevet fogjuk használni, ami: index.js
. A fájlok következő kilistázásánál egy alap index.js
fájlt látunk, amelyet a szerverünk belépési pontjaként fogunk használni:
const express = require('express')
const app = express()
const host = "myserver"
const port = 8080
app.get('/', (req, res) => {
res.send('Kérés fogadva')
})
app.listen(port, host, () => {
console.log(`A szerver kész a http://${host}:${port} címen`)
})
A szkript első soraiban a szerver konfigurációjához szükséges néhány fontos állandót definiálunk. Az első kettő, az express
és az app
, a beépített express
modulnak és ennek egy példányának felel meg, amely az alkalmazásunkat futtatja. A szerver által végrehajtandó műveleteket az app
objektumhoz adjuk hozzá.
A másik két konstans, a host
és a port
a kiszolgálóhoz tartozó hosztot és kommunikációs portot határozza meg.
Ha van egy nyilvánosan elérhető hosztunk, használjuk annak a nevét a myserver
helyett a host
értékeként. Ha nem adjuk meg a hoszt nevét, az Express alapértelmezés szerint a localhost
értéket fogja használni, vagyis azt a számítógépet, ahol az alkalmazás fut. Ebben az esetben egyetlen külső kliens sem fogja tudni elérni a programot; ez tesztelésre jó lehet, de a gyakorlatban kevés haszna lenne.
A portot meg kell adni, különben a szerver nem fog elindulni.
Ez a szkript csak két eljárást csatol az app
objektumhoz: az app.get()
műveletet, amely a kliensek által a HTTP GET
protokollon keresztül küldött kérésekre válaszol, és az app.listen()
hívást, amely a szerver aktiválásához szükséges, és amely hozzárendel egy hosztot és egy portot.
A szerver indításához futtassuk a node
parancsot, és adjuk meg a szkript nevét argumentumként:
$ node index.js
Amint megjelenik a A szerver kész a http://myserver:8080 címen
üzenet, a szerver készen áll a HTTP-kliens kéréseinek a fogadására. A kérések érkezhetnek ugyanazon a számítógépen lévő böngészőből, ahol a szerver fut, vagy egy másik, a szervert elérni képes gépről.
Az itt látható összes tranzakciós részlet megjelenik a böngészőben, ha megnyitjuk a fejlesztői konzol ablakot. Alternatívaként a curl
parancsot is használhatjuk a HTTP-kommunikációhoz, amellyel könnyebben ellenőrizhetjük a kapcsolat részleteit. Ha nem ismerjük a shell parancssort, létrehozhatunk egy HTML-űrlapot, amellyel kéréseket küldhetünk a szervernek.
A következő példa azt mutatja be, hogyan használhatjuk a parancssorban a curl
parancsot, hogy HTTP-kérést küldjön az újonnan telepített szervernek:
$ curl http://myserver:8080 -v * Trying 192.168.1.225:8080... * TCP_NODELAY set * Connected to myserver (192.168.1.225) port 8080 (#0) > GET / HTTP/1.1 > Host: myserver:8080 > User-Agent: curl/7.68.0 >Accept: / > * Mark bundle as not supporting multiuse < HTTP/1.1 200 OK < X-Powered-By: Express < Content-Type: text/html; charset=utf-8 < Content-Length: 16 < ETag: W/"10-1WVvDtVyAF0vX9evlsFlfiJTT5c" < Date: Fri, 02 Jul 2021 14:35:11 GMT < Connection: keep-alive < * Connection #0 to host myserver left intact Kérés fogadva
A curl
parancs -v
opciója megjeleníti az összes kérési és válasz fejlécet, valamint egyéb hibakeresési információkat. A >
-vel kezdődő sorok a kliens által küldött kérési fejléceket, a <
-vel kezdődő sorok pedig a szerver által küldött válaszfejléceket jelzik. A *
-gal kezdődő sorok a curl
által generált információk. A válasz tartalma csak a végén jelenik meg, ami ebben az esetben a Request received
sor.
A szolgáltatás URL-címét, amely ebben az esetben a szerver hosztnevét és portját (http://myserver:8080
) tartalmazza, a curl
parancs argumentumaként adtuk meg. Mivel nincs megadva könyvtár vagy fájlnév, ezek alapértelmezés szerint a /
gyökérkönyvtárat jelölik. A slash a > GET / HTTP/1.1
sorban a kérési fájlként jelenik meg, amelyet a kimeneten a hosztnév és a port követ.
A HTTP kapcsolat fejlécének megjelenítésén kívül a curl
parancs segíti az alkalmazásfejlesztést azzal, hogy lehetővé teszi az adatok küldését a szervernek különböző HTTP-módszerekkel és különböző formátumokban. Ez a rugalmasság megkönnyíti a hibakeresést és az új funkciók implementálását a szerveren.
Utak
A kliens által a szerverhez intézhető kérések attól függnek, hogy milyen utakat (route) definiáltunk az index.js
fájlban. Egy út megadja a HTTP-módszert és definiál egy útvonalat (pontosabban egy URI-t), amelyet a kliens kérhet.
Eddig a szervernek csak egy út van beállítva:
app.get('/', (req, res) => {
res.send('Kérés fogadva')
})
Bár ez egy nagyon egyszerű út, amely egyszerűen csak egy egyszerű szöveges üzenetet küld vissza a kliensnek, elég ahhoz, hogy azonosítsuk a legfontosabb összetevőket, amelyeket a legtöbb út felépítéséhez használnak:
-
Az út által kiszolgált HTTP-metódus. A példában a HTTP
GET
módszert azapp
objektumget
tulajdonsága jelzi. -
Az út által kiszolgált útvonal. Ha a kliens nem ad meg elérési utat a kéréshez, a szerver a gyökérkönyvtárat használja, amely a webszerver által használatra fenntartott alapkönyvtár. A lecke egy későbbi példája az
/echo
elérési utat használja, ami amyserver:8080/echo
címre küldött kérésnek felel meg. -
A függvény, amely akkor hajtódik végre, amikor a szerver kérést kap ezen az útvonalon, általában rövidített formában nyíl függvényként (arrow function) írva, mivel a
⇒
szintaxis a névtelen függvény definíciójára mutat. Areq
paraméter (a “request” rövidítése) és ares
paraméter (a “response” rövidítése) a kapcsolat adatait adja meg, amelyeket maga az alkalmazáspéldány ad át a függvénynek.
POST módszer
A tesztszerverünk funkcionalitásának bővítéséhez először nézzük meg, hogyan definiálhatunk utat a HTTP POST
módszerhez. Ezt a kliensek akkor használják, ha a kérés fejlécében szereplő adatokon túl további adatokat kell küldeniük a szervernek. A curl
parancs --data
opciója automatikusan meghívja a POST
módszert, és tartalmazza a POST
módszerrel a szervernek küldendő tartalmat. Az alábbi kimeneten a POST / HTTP/1.1
sor azt mutatja, hogy a POST
módszert volt használva. A szerverünk azonban csak GET
metódust definiált, így hiba lép fel, amikor a curl
segítségével POST
-tal küldünk kérést:
$ curl http://myserver:8080/echo --data message="Ez a POST kérés törzse" * Trying 192.168.1.225:8080... * TCP_NODELAY set * Connected to myserver (192.168.1.225) port 8080 (#0) > POST / HTTP/1.1 > Host: myserver:8080 > User-Agent: curl/7.68.0 >Accept: / > Content-Length: 37 > Content-Type: application/x-www-form-urlencoded > * upload completely sent off: 37 out of 37 bytes * Mark bundle as not supporting multiuse < HTTP/1.1 404 Not Found < X-Powered-By: Express < Content-Security-Policy: default-src 'none' < X-Content-Type-Options: nosniff < Content-Type: text/html; charset=utf-8 < Content-Length: 140 < Date: Sat, 03 Jul 2021 02:22:45 GMT < Connection: keep-alive < <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <title>Error</title> </head> <body> <pre>Cannot POST /</pre> </body> </html> * Connection #0 to host myserver left intact
Az előző példában a curl
futtatása a --data message="Ez a POST kérés törzse"
paraméterrel megfelel egy olyan űrlap elküldésének, amely a message
nevű szövegmezőt tartalmazza, és amelyet a Ez a POST kérés törzse
paraméterrel töltünk ki.
Mivel a szerver csak egy utat konfigurált a /
útvonalhoz, és ez az út csak a HTTP GET
módszerre válaszol, ezért a válasz fejlécében a HTTP/1.1 404 Not Found
sor szerepel. Ezenkívül az Express automatikusan generált egy rövid HTML választ a Cannot POST
figyelmeztetéssel.
Miután megnéztük, hogy hogyan generálhatunk POST
kérést a curl
segítségével, írjunk egy Express programot, amely sikeresen kezeli a kérést.
Először is, figyeljük meg, hogy a kérés fejlécében a Content-Type
mező azt tartalmazza, hogy a kliens által küldött adatok az application/x-www-form-urlencoded
formátumúak. Az Express alapértelmezés szerint nem ismeri ezt a formátumot, ezért az express.urlencoded
modult kell használnunk. Ha ezt a modult beépítjük, a req
objektum—amelyet paraméterként adunk át a kezelő függvénynek—megkapja a req.body.message
tulajdonságot, amely megfelel a kliens által küldött message
mezőnek. A modul betöltése az app.use
segítségével történik, amelyet az utak deklarálása elé kell elhelyezni:
const express = require('express')
const app = express()
const host = "myserver"
const port = 8080
app.use(express.urlencoded({ extended: true }))
Ha ez megtörtént, elég lenne az app.get
-et app.post
-ra változtatni a meglévő útban, hogy teljesíteni lehessen a POST
-on keresztül érkező kéréseket, és vissza lehessen állítani a kérés törzsét:
app.post('/', (req, res) => {
res.send(req.body.message)
})
Az út lecserélése helyett egy másik lehetőség az lenne, ha egyszerűen hozzáadnánk ezt az új utat, mivel az Express képes azonosítani a HTTP-módszert a kérés fejlécében, és így a megfelelő utat használná. Mivel egynél több szolgáltatást szeretnénk hozzáadni ehhez a szerverhez, célszerű az egyes szolgáltatásokat saját útvonallal elválasztani, például /echo
és /ip
.
Útvonal- és szolgáltatáskezelő
Miután meghatároztuk, hogy melyik HTTP-módszer fog válaszolni a kérésre, most meg kell határoznunk egy konkrét elérési utat az erőforráshoz és egy függvényt, amely feldolgozza és létrehozza a választ a kliens részére.
A szerver echo
funkcionalitásának bővítéséhez definiálhatunk egy utat a POST
módszerrel és az /echo
útvonallal:
app.post('/echo', (req, res) => {
res.send(req.body.message)
})
A kezelő függvény req
paramétere tartalmazza a kérés összes tulajdonságként tárolt részletét. A kérés törzsében lévő message
mező tartalma a req.body.message
tulajdonságban érhető el. A példa egyszerűen ezt a mezőt küldi vissza a kliensnek a res.send(req.body.message)
híváson keresztül.
Ne feledjük, hogy a módosítások csak a szerver újraindítása után lépnek életbe. Mivel a fejezet példái során a szervert egy terminálablakból futtatjuk, a szervert a terminálban a kbd:[Ctrl+C] billentyűkombinációval tudjuk leállítani, ezután a node index.js
paranccsal lehet újraindítani. A kliens által a korábban bemutatott curl
kérésre kapott válasz most már sikeres:
$ curl http://myserver:8080/echo --data message="Ez a POST kérés törzse" Ez a POST kérés törzse
Az információ átadásának és visszaküldésének egyéb módjai egy GET-kérésben
A HTTP POST
módszer használata túlzás lehet, ha csak rövid szöveges üzeneteket küldünk, mint amilyen a példában is szerepel. Ilyen esetekben az adatokat egy kérdőjellel kezdődő query string-ben is el lehet küldeni. Így a ?message=Ez+az+üzenet
sztringet a HTTP GET
módszer kérési útvonalába lehet beilleszteni. A query stringben használt mezők a szerver számára a req.query
tulajdonságban állnak rendelkezésre, ezért a message
nevű mező elérhető a req.query.message
tulajdonságban.
A HTTP GET
módszerrel történő adatküldés másik módja az Express route paramétereinek használata:
app.get('/echo/:message', (req, res) => {
res.send(req.params.message)
})
A példában szereplő út megfelel a GET
módszerrel az /echo/:message
útvonalat használó kéréseknek, ahol a :message
egy placeholder a kliens által ezzel a címkével küldött bármely kifejezés számára. Ezek a paraméterek a req.params
tulajdonságban érhetőek el. Ezzel az új úttal a szerver echo
függvényét a kliens tömörebben kérheti le:
$ curl http://myserver:8080/echo/hello hello
Más helyzetekben a szervernek a kérés feldolgozásához szükséges információkat nem kell kifejezetten a kliensnek megadnia. Például a szervernek más módja is van a kliens nyilvános IP-címének lekérdezésére. Ez az információ alapértelmezés szerint megtalálható a req
objektumban, a req.ip
tulajdonságban:
app.get('/ip', (req, res) => {
res.send(req.ip)
})
Most a kliens a /ip
elérési útvonalat kéri le a GET
módszerrel, hogy megkeresse saját, nyilvános IP-címét:
$ curl http://myserver:8080/ip 187.34.178.12
A req
objektum egyéb tulajdonságait a kliens módosíthatja, különösen a kérés fejléceit, amelyek a req.headers
mezőben érhetők el. A req.headers.user-agent
tulajdonság például azonosítja, hogy melyik program küldi a kérést. Bár nem általános gyakorlat, a kliens megváltoztathatja ennek a mezőnek a tartalmát, ezért a szervernek nem szabad ezt a mezőt egy adott kliens megbízható azonosítására használnia. Még fontosabb a kliens által kifejezetten megadott adatok hitelesítése, hogy elkerüljük a határok és formátumok közötti ellentmondásokat, amelyek hátrányosan befolyásolhatják az alkalmazást.
A válasz módosításai
Ahogy a korábbi példákban láttuk, a res
paraméter felelős a válasz klienshez való eljuttatásáért. Továbbá a res
objektum a válasz egyéb aspektusait is megváltoztathatja. Észrevehettük, hogy bár az eddig megvalósított válaszok csak rövid, egyszerű szöveges üzenetek, a válaszok Content-Type
fejlécében a text/html; charset=utf-8
címkét használjuk. Bár ez nem akadályozza meg a sima szöveges válaszok elfogadását, helyesebb megoldás, ha a válasz fejlécében ezt a mezőt res.type('text/plain')
beállítással text/plain
-re definiáljuk át.
A válaszok más típusú módosításai a sütik (cookie) használatát foglalják magukban, amelyek lehetővé teszik a szerver számára, hogy azonosítsa a korábban kérést benyújtó klienst. A sütik fontosak a fejlett szolgáltatásokhoz, például az olyan privát munkamenetek létrehozásához, amelyek a kéréseket egy adott felhasználóhoz rendelik, de itt most csak egy egyszerű példát nézünk meg arra, hogyan lehet egy sütit használni egy olyan kliens azonosítására, aki korábban már elérte a szervert.
Tekintettel az Express moduláris felépítésére, a sütik menedzselését az npm
paranccsal kell telepíteni, mielőtt a szkriptben használnánk:
$ npm install cookie-parser
A telepítés után a sütik kezelését be kell építeni a szerver szkriptjébe. A következő definíciót a fájl elejéhez közel kell beilleszteni:
const cookieParser = require('cookie-parser')
app.use(cookieParser())
A sütik használatának illusztráláshoz módosítsuk az útkezelő függvényt a /
gyökér elérési útvonalával, amely már létezik a szkriptben. A req
objektum rendelkezik egy req.cookies
tulajdonsággal, ahol a kérés fejlécében elküldött sütiket tároljuk. A res
objektumnak viszont van egy res.cookie()
metódusa, amely létrehoz egy új sütit, amelyet elküld a kliensnek. A következő példában szereplő kezelőfüggvény ellenőrzi, hogy létezik-e a kérésben known
nevű süti. Ha ilyen süti nem létezik, a kiszolgáló feltételezi, hogy a látogató először jár itt, és a res.cookie('known', '1')
híváson keresztül elküldi neki az ilyen nevű sütit. A sütihez önkényesen az 1
értéket rendeljük, mert feltételezhetően van valamilyen tartalma, de a szerver nem kérdezi meg ezt az értéket. Ez az alkalmazás csak feltételezi, hogy a süti egyszerű jelenléte azt jelzi, hogy a kliens már korábban is lekérte ezt az utat:
app.get('/', (req, res) => {
res.type('text/plain')
if ( req.cookies.known === undefined ){
res.cookie('known', '1')
res.send('Üdv, új látogató!')
}
else
res.send('Üdv újra itt, látogató');
})
Alapértelmezés szerint a curl
nem használ sütiket a tranzakciókban. De van lehetőség a tárolásra (-c cookies.txt
) és a tárolt cookie-k elküldésére (-b cookies.txt
):
$ curl http://myserver:8080/ -c cookies.txt -b cookies.txt -v * Trying 192.168.1.225:8080... * TCP_NODELAY set * Connected to myserver (192.168.1.225) port 8080 (#0) > GET / HTTP/1.1 > Host: myserver:8080 > User-Agent: curl/7.68.0 >Accept: / > * Mark bundle as not supporting multiuse < HTTP/1.1 200 OK < X-Powered-By: Express < Content-Type: text/plain; charset=utf-8 * Added cookie known="1" for domain myserver, path /, expire 0 < Set-Cookie: known=1; Path=/ < Content-Length: 21 < ETag: W/"15-l7qrxcqicl4xv6EfA5fZFWCFrgY" < Date: Sat, 03 Jul 2021 23:45:03 GMT < Connection: keep-alive < * Connection #0 to host myserver left intact Üdv, új látogató!
Mivel ez a parancs volt az első hozzáférés azóta, hogy a szerveren bevezetésre kerültek a sütik, a kliens nem rendelkezett olyan sütikkel, amelyeket a kéréshez csatolhatott volna. Ahogyan az várható volt, a szerver nem azonosította a sütit a kérésben, ezért a sütit a válasz fejlécébe is belefoglalta, amint azt a kimenet "Set-Cookie: known=1; Path=/" sora is jelzi. Mivel engedélyeztük a sütiket a curl
-ben, egy új kérés a kérés fejlécében tartalmazza a known=1
sütit, így a kiszolgáló azonosítani tudja a süti jelenlétét:
$ curl http://myserver:8080/ -c cookies.txt -b cookies.txt -v * Trying 192.168.1.225:8080... * TCP_NODELAY set * Connected to myserver (192.168.1.225) port 8080 (#0) > GET / HTTP/1.1 > Host: myserver:8080 > User-Agent: curl/7.68.0 >Accept: / > Cookie: known=1 > * Mark bundle as not supporting multiuse < HTTP/1.1 200 OK < X-Powered-By: Express < Content-Type: text/plain; charset=utf-8 < Content-Length: 21 < ETag: W/"15-ATq2flQYtLMYIUpJwwpb5SjV9Ww" < Date: Sat, 03 Jul 2021 23:45:47 GMT < Connection: keep-alive < * Connection #0 to host myserver left intact Üdv újra, látogató
A sütik biztonsága
A fejlesztőnek tisztában kell lennie a lehetséges sebezhetőségekkel, ha sütiket használ a kéréseket küldő kliensek azonosítására. A támadók olyan technikákat használhatnak, mint a cross-site scripting (XSS) és a cross-site request forgery (CSRF), hogy ellopják a klienstől a sütiket, és ezáltal megszemélyesítsék őt, amikor kérést intéz a szerverhez. Általánosságban elmondható, hogy az ilyen típusú támadások nem validált megjegyzésmezőket vagy aprólékosan felépített URL-címeket használnak rosszindulatú JavaScript-kód beillesztésére az oldalba. Amikor egy autentikált kliens végrehajtja, ez a kód képes az érvényes sütiket lemásolni és tárolni vagy továbbítani egy másik célállomásra.
Ezért a professzionális alkalmazásokban különösen fontos, hogy speciálisabb Express funkciókat, úgynevezett middleware-t (köztes szoftver) telepítsünk és használjunk. Az express-session
vagy cookie-session
modulok teljesebb és biztonságosabb ellenőrzést biztosítanak a munkamenet és a sütik kezelése felett. Ezek a komponensek extra ellenőrzéseket tesznek lehetővé annak megakadályozására, hogy a sütiket eltérítsék eredeti kibocsátójuktól.
Gyakorló feladatok
-
Hogyan lehet a HTTP
GET
módszer query string-ben elküldöttcomment
mező tartalmát beolvasni egy kezelőfüggvényben? -
Írjunk egy útvonalat, amely a HTTP
GET
módszert és a/agent
elérési utat használja auser-agent
fejléc tartalmának visszaküldésére a kliensnek! -
Az Express.js rendelkezik egy route parameters nevű funkcióval, ahol a kliens által küldött
name
paraméter fogadására egy olyan útvonal használható, mint például a/user/:name
. Hogyan érhető el aname
paraméter az útvonal kezelőfüggvényén belül?
Gondolkodtató feladatok
-
Ha egy szerver hosztneve
myserver
, akkor melyik Express útvonal kapná meg az alábbi űrlapon szereplő kérést?<form action="/contact/feedback" method="post"> ... </form>
-
A szerver fejlesztése során a programozó nem tudja kiolvasni a
req.body
tulajdonságot, még akkor sem, ha ellenőrizte, hogy a kliens helyesen küldi-e a tartalmat a HTTPPOST
módszerrel. Mi lehet a probléma legvalószínűbb oka? -
Mi történik, ha a szervernek van egy útvonala a
/user/:name
elérési útvonalra beállítva, és a kliens a/user/
elérési útvonalat kéri?
Összefoglalás
Ez a lecke elmagyarázza, hogyan írhatunk Express szkripteket a HTTP-kérések fogadására és kezelésére. Az Express a routes (utak) koncepciót használja az ügyfelek számára elérhető erőforrások meghatározására, ami nagy rugalmasságot biztosít bármilyen webes alkalmazás kiszolgálóinak felépítéséhez. Ez a lecke a következő fogalmakat és eljárásokat veszi át:
-
A HTTP
GET
és HTTPPOST
módszereket használó utak. -
Az űrlapadatok tárolása a
request
objektumban. -
Utak paramétereinek használata.
-
Válaszfejlécek testreszabása.
-
Sütik alapvető kezelése.
Válaszok a gyakorló feladatokra
-
Hogyan lehet a HTTP
GET
módszer query string-ben elküldöttcomment
mező tartalmát beolvasni egy kezelőfüggvényben?A
comment
mező elérhető areq.query.comment
tulajdonságban. -
Írjunk egy útvonalat, amely a HTTP
GET
módszert és a/agent
elérési utat használja auser-agent
fejléc tartalmának visszaküldésére a kliensnek!app.get('/agent', (req, res) => { res.send(req.headers.user-agent) })
-
Az Express.js rendelkezik egy route parameters nevű funkcióval, ahol a kliens által küldött
name
paraméter fogadására egy olyan útvonal használható, mint például a/user/:name
. Hogyan érhető el aname
paraméter az útvonal kezelőfüggvényén belül?A
name
paraméter areq.params.name
tulajdonságban érhető el.
Válaszok a gondolkodtató feladatokra
-
Ha egy szerver hosztneve
myserver
, akkor melyik Express útvonal kapná meg az alábbi űrlapon szereplő kérést?<form action="/contact/feedback" method="post"> ... </form>
app.post('/contact/feedback', (req, res) => { ... })
-
A szerver fejlesztése során a programozó nem tudja kiolvasni a
req.body
tulajdonságot, még akkor sem, ha ellenőrizte, hogy a kliens helyesen küldi-e a tartalmat a HTTPPOST
módszerrel. Mi lehet a probléma legvalószínűbb oka?A programozó nem adta hozzá az
express.urlencoded
modult, amely lehetővé teszi az Express számára, hogy kibontsa a kérés törzsét. -
Mi történik, ha a szervernek van egy útvonala a
/user/:name
elérési útvonalra beállítva, és a kliens a/user/
elérési útvonalat kéri?A szerver egy
404 Not Found
üzenetet küld, mivel az út megköveteli, hogy a:name
paramétert a kliens adja meg.