2016-05-11 42 views
5

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, digita localhost: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 a localhost: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 ci require '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)?

risposta

5

Hai ragione sulla tua comprensione. HTTP è solo un protocollo basato su testo che, come molti, opera su TCP/IP.

Il server WEBrick incorporato non è il miglior esempio di server HTTP scritto in Ruby, ma è incluso per motivi legacy perché è spesso "abbastanza buono" per iniziare. Pow è considerevolmente migliore e nonostante sia prodotto dalla stessa azienda che ha prodotto Rails è scritto in gran parte in Nodo.

La bellezza di HTTP, come molti protocolli basati su Internet, è che non importa quale lingua si utilizza purché si rispetti lo standard.

Rack è un livello che opera dietro HTTP e fornisce un sottile strato di astrazione sul ciclo richiesta/risposta.

+0

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

+0

@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

+0

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

2

Un server è qualcosa che apre una porta (80, 443, 8080) per una sorta di trasferimento di dati. La porta 80 è la porta HTTP e la porta 443 è la porta HTTPS. 8080 è una porta comunemente utilizzata per lo sviluppo (come 3000).https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers

Un server locale, per definizione, è un server in esecuzione sulla macchina.

Nel complesso, siete decisamente sulla buona strada.