Posso programmare e sviluppare in Ruby on Rails/JS/HTML/CSS per creare un'app completa. Tuttavia, ci sono dei buchi nella mia comprensione del ciclo di richiesta/risposta HTTP. I seguenti punti sono corretti?Che cosa significa eseguire un server Web locale?
- Se creo un'app Rails e sul tipo di riga di comando
rails server
ottengo un server locale a cui posso effettuare richieste. Se apro un browser, digitalocalhost:3000
e premi invio, sto facendo una richiesta HTTP al server locale. - Rails utilizza per impostazione predefinita un server Web chiamato WEBrick, sebbene ce ne siano altri come Thin, Puma e Unicorn. Questi sono tutti pezzi di software e ciò che li rende server Web è il fatto che il software implementa le funzionalità per elaborare le richieste HTTP.
- Quando eseguo un server Web locale, significa che il mio computer sta eseguendo uno di questi software che ascolta le richieste HTTP.
È quanto indicato sopra "per eseguire un server Web locale"?
- Ho visto altri esempi di modi per "eseguire un server Web locale". Uno dei è quello di eseguire
npm install -g http-server
in una directory di progetto e quindi passare alocalhost:8080
. Questo è anche solo il software che inizia a funzionare e accetta richieste HTTP sulla porta 8080? - Su una riga di comando Ruby, installare gemma del rack:
gem install rack
. Poi, in un nuovo file di Ruby cirequire 'rack'
, avviare un server web:
Rack::Server.start({ app: MySimpleApp, port: 3000 })
Possiamo quindi definire un'applicazione web MySimpleApp
che è cremagliera-compliant (oggetto che risponde al call
metodo):
class MySimpleApp
def self.call
(...)
end
end
Così ora, quando navighiamo nel nostro browser su localhost: 3000, viene eseguita MySimpleApp. Il rack sta semplicemente eseguendo il server WEBrick predefinito? È ciò che i comandi precedenti fanno semplicemente eseguire un server web locale e definire cosa fare quando viene richiesta una richiesta HTTP (eseguire MySimpleApp)?
Attenzione al primo paragrafo: HTTP potrebbe * sembrare * come se fosse basato su testo. Ma in realtà è un protocollo binario: funziona su ottetti, non su caratteri. – DaSourcerer
@DaSourcerer Non sono sicuro che sia una distinzione importante per un protocollo basato su ASCII 7 bit o estensioni per [codificare altri formati] (https://tools.ietf.org/html/rfc5987). Byte e caratteri sono uguali qui se non diversamente specificato. L'inquadratura è in chiaro. I payload * possono * essere binari. – tadman
Non iniziare a litigare per questo, ma sì, mentre nella pratica è visibile, è importante. Codewords e delimitatori che si inseriscono in ASCII a 7 bit sono in realtà un modo per evitare problemi di interoperabilità e consentire la lettura a byte del protocollo. Oh, e alcune intestazioni introdotte prima che RFC 5987 consenta i payload UTF8 non elaborati. 'Cookie2' è uno di questi, penso. – DaSourcerer