CodeGym /Java Blog /Random-IT /Parte 3. HTTP/HTTPS
John Squirrels
Livello 41
San Francisco

Parte 3. HTTP/HTTPS

Pubblicato nel gruppo Random-IT
Questo materiale fa parte della serie "Introduzione allo sviluppo aziendale". Articoli precedenti: Parte 3. HTTP/HTTPS - 1CIAO! Oggi impareremo i protocolli HTTP e HTTPS. Ma prima chiariamo un punto: stiamo parlando di protocolli per l'invio di dati in rete a livello applicativo del modello OSI. Ricorderete che abbiamo conosciuto il modello OSI in uno degli articoli precedenti. Se non te lo ricordi, eccolo qui .

Cos'è un protocollo di comunicazione dati?

Questo è ciò che chiamiamo l'insieme concordato di regole che consente agli sviluppatori di diversi servizi di inviare informazioni in un formato comprensibile agli altri. Ad esempio, puoi utilizzare Google Chrome per ottenere informazioni sia da Facebook che da Twitter, perché gli sviluppatori le inviano utilizzando il protocollo HTTP standard, che consente al tuo browser di elaborarle. Le regole uniformi sono molto convenienti per le persone che sviluppano la parte server: ci sono molte librerie che possono convertire le informazioni per te e inviarle utilizzando il protocollo appropriato. HTTP è stato inizialmente concepito come un protocollo per l'invio di pagine HTML. Questo è il modo in cui è stato usato per molto tempo, ma ora i programmatori lo usano spesso per inviare sia stringhe che file multimediali. In generale, questo protocollo è universalmente accettato e versatile ed è davvero facile da usare. E ora esamineremo come usarlo.

La struttura dell'HTTP

Dovremmo notare subito che il protocollo HTTP consiste solo di testo. Ciò che più ci interessa è la struttura di questo testo. Ogni messaggio è composto da tre parti:
  1. Linea di partenza: definisce alcuni dati di pulizia.
  2. Intestazioni: descrivono i parametri del messaggio.
  3. Corpo: questo è il contenuto del messaggio. Il corpo deve essere separato dalle intestazioni da una riga vuota.
Il protocollo HTTP viene utilizzato per inviare richieste a un server e ricevere risposte dal server. I parametri delle richieste e delle risposte sono leggermente diversi.

Ecco come appare una semplice richiesta HTTP:


GET / HTTP/1.1
Host: codegym.cc
User-Agent: firefox/5.0 (Linux; Debian 5.0.8; en-US; rv:1.8.1.7)
La linea di partenza indica:
  • GET — Il metodo della richiesta
  • / — Il percorso della richiesta
  • HTTP/1.1 — La versione del protocollo
Poi arrivano le intestazioni:
  • Host : l'host a cui è indirizzata la richiesta
  • User-Agent : il client che invia la richiesta
Manca il corpo del messaggio. In una richiesta HTTP, sono richieste solo la riga iniziale e l'intestazione "Host". Ora diamo un'occhiata a tutto un passo alla volta. Una richiesta HTTP deve contenere un metodo. Ce ne sono nove: GET, POST, PUT, OPTIONS, HEAD, PATCH, DELETE, TRACE, CONNECT. I più comuni sono GET e POST. Questi due metodi saranno inizialmente sufficienti. GET — Questo metodo richiede il contenuto dal server. Di conseguenza, le richieste con il metodo GET non hanno un corpo del messaggio. Ma se necessario, puoi passare i parametri tramite il percorso (nella riga di partenza) nel seguente formato:

https://cdn.codegym.cc/images/article/155cea79-acfd-4968-9361-ad585e939b82/original.pngsend?name1=value1&name2=value2
dove codegym.cc è l'host, /send è il percorso della richiesta e ? è un separatore che indica che seguono i parametri della query. Alla fine, vengono elencate le coppie chiave-valore ("chiave=valore"), separate da una e commerciale. POST — Questo metodo pubblica informazioni sul server. Una richiesta POST può inviare vari tipi di informazioni: parametri come coppie "chiave=valore", JSON, codice HTML o persino file. Tutte le informazioni vengono inviate nel corpo del messaggio. Per esempio:

POST /user/create/json HTTP/1.1
Accept: application/json
Content-Type: application/json
Content-Length: 28
Host: codegym.cc

{
  "Id": 12345,
  "User": "John"
}
La richiesta viene inviata a codegym.cc/user/create/json e la versione del protocollo è HTTP/1.1. "Accetta" indica il formato della risposta che il client si aspetta di ricevere. "Content-Type" indica il formato del corpo del messaggio inviato nella richiesta. "Content-Length" è il numero di caratteri nel corpo. Una richiesta HTTP può contenere molte intestazioni diverse. Per ulteriori informazioni, dai un'occhiata alle specifiche del protocollo .

Risposte HTTP

Dopo aver ricevuto una richiesta, il server la elabora e invia una risposta al client:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 98

<html>
  <head>
    <title>An Example Page</title>
  </head>
  <body>
    <p>Hello World</p>
  </body>
</html>
La riga iniziale della risposta contiene la versione del protocollo (HTTP/1.1), il codice di stato (200) e la descrizione dello stato (OK). Le sue intestazioni includono il tipo e la lunghezza del contenuto. Il corpo della risposta contiene codice HTML che il browser visualizza come pagina HTML.

Codici di stato della risposta

Tutto è chiaro per quanto riguarda il corpo del messaggio e le intestazioni, ma dovremmo spendere qualche parola sui codici di stato. I codici di stato della risposta sono sempre di tre cifre. La prima cifra del codice indica la categoria della risposta:
  • 1xx - Informativo. La richiesta è stata accolta. Il server è pronto per continuare.
  • 2xx — Riuscito. La richiesta è stata ricevuta, compresa ed elaborata.
  • 3xx — Reindirizzamento. È necessario eseguire azioni aggiuntive per elaborare la richiesta.
  • 4xx: errore del client. La richiesta contiene errori o non è conforme al protocollo.
  • 5xx: errore del server. La richiesta è stata composta correttamente, ma il server non è stato in grado di elaborarla.
La seconda e la terza cifra del codice indicano una risposta più specifica. Per esempio:
  • 200 OK — La richiesta è stata ricevuta ed elaborata correttamente.
  • 201 Creato: la richiesta è stata ricevuta ed elaborata correttamente, con conseguente creazione di una nuova risorsa o istanza.
  • 301 Moved Permanently — La risorsa richiesta è stata spostata in modo permanente. Le richieste successive dovranno essere effettuate utilizzando il nuovo indirizzo.
  • 307 Reindirizzamento temporaneo — La risorsa è stata spostata temporaneamente. Per ora, è possibile accedervi utilizzando l'inoltro automatico.
  • 403 Forbidden — La richiesta è stata capita, ma è necessaria l'autorizzazione.
  • 404 Not Found — Il server non ha trovato la risorsa a questo indirizzo.
  • 501 Not Implemented — Il server non supporta la funzionalità richiesta per rispondere alla richiesta.
  • 505 Versione HTTP non supportata: il server non supporta la versione specificata del protocollo HTTP.
Oltre al codice di stato della risposta, viene inviata anche una descrizione dello stato. Questo aiuta a chiarire cosa significa ogni stato specifico. Il protocollo HTTP è molto pratico: fornisce un gran numero di intestazioni, che puoi utilizzare per organizzare una comunicazione molto flessibile tra un client e un server. Una considerazione completa di tutte le intestazioni di richiesta e risposta, metodi di richiesta e codici di stato della risposta sarebbe troppo per un singolo articolo. Se necessario, puoi leggere le specifiche ufficiali del protocollo, che descrive tutte le sfumature. È consuetudine utilizzare il protocollo HTTP sulla porta 80, quindi quando vedi un URL che termina con la porta 80, puoi essere sicuro di dover utilizzare HTTP per accedervi. Con l'evolversi della tecnologia e l'inizio dell'invio di dati personali su Internet, è diventato necessario pensare a come fornire una protezione aggiuntiva per le informazioni che il client invia al server. Il risultato di questo pensiero è stato il protocollo HTTPS.

La differenza tra HTTPS e HTTP

In termini di sintassi, HTTPS è identico al protocollo HTTP. Cioè, utilizza le stesse linee di partenza e intestazioni. Le uniche differenze sono la crittografia aggiuntiva e la porta predefinita (443) . HTTPS è crittografato tra HTTP e TCP, ovvero tra l'applicazione e il livello di trasporto. Se hai dimenticato cosa significa, dai un'occhiata all'articolo sul modello OSI . Lo standard di crittografia odierno è TLS. Non entreremo troppo in questo argomento, ma ricorda che la crittografia avviene prima che le informazioni raggiungano il livello di trasporto. In HTTPS, assolutamente tutte le informazioni sono crittografate, ad eccezione dell'host e della porta a cui viene inviata la richiesta. Il passaggio da un server all'uso del protocollo HTTPS invece di HTTP non richiede l'utilizzo per modificare il codice del server. Questa funzionalità è abilitata nei contenitori servlet, di cui parleremo in articoli successivi. E questo è tutto per oggi. In realtà, aspetta un momento. Per mettere le mani su alcune richieste HTTP, apri Google Chrome, premi F12 e seleziona la scheda "Rete". Tutte le richieste e le risposte inviate/ricevute dal tuo browser verranno visualizzate qui. Parte 4. Le basi di Maven Parte 5. Servlet e Java Servlet API. Scrivere una semplice applicazione web Parte 6. Contenitori servlet Parte 7. Introduzione al pattern MVC (Model-View-Controller)
Commenti
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION