C'è qualche differenza tra i parametri in un URL e < form method = & # 8220; get & # 8221; > ;?

Question

Ora conosco una differenza tra i parametri in un URL e un parametro POST: alcuni browser potrebbero comportarsi in modo errato se l'URL è troppo lungo, quindi non è una buona idea inserire centinaia di parametri in un URL, anche se la tua app può rispondere a una richiesta GET.

Per motivi di discussione, supponiamo che la seguente applicazione Web: un utente possa inserire una serie di (possibilmente centinaia di) coordinate X, Y. Il server li traccia in un grafico, che viene restituito come immagine.

Questo è chiaramente un esempio di operazione idempotente , quindi, secondo la specifica HTTP , si consiglia di implementarlo come operazione GET. Tuttavia, non è possibile creare un URL con tutti i parametri, poiché sarà troppo lungo. Può < form method = " get " > gestire così tanti parametri?

Ho anche sentito che < form method = " get " > equivale completamente a inserire i parametri in un URL? Ora, è vero per alcuni browser o per l'intero protocollo HTTP? C'è una lunghezza massima per una richiesta?

Answer 1

Le specifiche HTTP non impongono limiti, ma lo fanno i browser e i server. Vedi qui per dettagli.

Il browser creerà un URL lungo se il metodo è impostato su GET per un modulo, quindi si applicano le limitazioni di cui sopra.

Answer 2

La specifica HTTP non richiede esplicitamente di posizionare i parametri di un GET richiesta nell'URI. Sarebbe legale inviare un corpo di messaggio in una richiesta GET come fanno i moduli utilizzando POST.

Tuttavia, i browser implementano i moduli GET in questo modo per un'ottima ragione: memorizzazione nella cache. Le richieste GET dovrebbero essere elaborate sul server senza effetti collaterali. Quindi le risposte alle richieste GET potrebbero essere memorizzate nella cache. Questa opzione di miglioramento delle prestazioni viene persa all'istante se inizi a utilizzare i corpi dei messaggi sulle richieste GET.

Se prevedi di progettare un'API per grafici, potresti dare un'occhiata a Google . Ne offrono già un ottimo al pubblico. Anche se è solo per imparare a impacchettare quante più informazioni possibili nei parametri URI, vale la pena dare un'occhiata.

& nbsp; & nbsp; & nbsp;

Answer 3

Quello che fa il tuo browser è creare un URL molto lungo dagli input del modulo. Pertanto, non vi sarà alcuna differenza tra un URL e un modulo Metodo = " OTTIENI " ;. Uno dei due comporterà il caricamento dello stesso URL.

Answer 4

form method = get WILL inserirà tutti gli input del modulo nell'URL.

È vero che i browser hanno una lunghezza massima per l'URL. Passa dai browser ai browser e sicuramente dalla versione dei browser alla versione dei browser.

Se puoi, ti consiglierei di usare POST per il tuo modulo.

HTH

Answer 5

OTTIENI e url? name = value & amp; ... sono la stessa cosa, poiché il browser converte semplicemente un modulo GET in un URL prima di inviare la richiesta.

La lunghezza massima dell'URL è determinata a livello di browser e server, quindi, per un determinato browser / server, è la più piccola delle due.

Questo post ha un buon elenco delle lunghezze massime correnti per gli URL

Answer 6

No, un server non può vedere la differenza tra l'inserimento di parametri in un URL e l'utilizzo di un FORM con un metodo GET. Pertanto, se un determinato URL con parametri sarebbe troppo lungo, l'utilizzo di un FORM con un metodo GET non sarà di aiuto.

POST o GET dovrebbero essere scelti principalmente per la loro semantica. OTTENERE è per "sicuro" Azioni. Cioè, gli utenti non devono essere ritenuti responsabili per un'operazione eseguita da una richiesta GET. Il metodo POST viene utilizzato per le operazioni per le quali l'utente deve essere ritenuto responsabile.

È molto frustrante, ad esempio, quando una funzione di ricerca utilizza POST. Un utente non si aspetta che una semplice query modifichi alcun importante stato del sistema: si aspetta che la ricerca sia "sicura". operazione.

D'altra parte, esistono molte vulnerabilità perché le operazioni non sicure sono accessibili tramite richieste GET e POST. Ciò contribuisce a vulnerabilità come XSRF in cui un utente malintenzionato deve semplicemente ottenere un malware "quot" URL in un tag IMG su un sito legittimo.

Per il tuo caso d'uso, Ajax potrebbe effettivamente essere una soluzione appropriata. È possibile effettuare una richiesta GET per ciascun punto selezionato, memorizzandoli in una sessione sul server. Quando l'utente ha finito di inserire i punti, una richiesta GET finale recupera il prodotto finito.

Answer 7

Questa non è una risposta alla tua domanda su get e post ma in una situazione come quella che stai descrivendo è abbastanza spesso più facile archiviare i dati più complessi sul server e associarli a un ID di sessione o un account utente piuttosto che inserirlo ogni volta nell'URL. Quindi puoi utilizzare solo l'identificatore per quella sessione in un cookie o come parametro url per recuperare l'immagine.

Ciò può anche aiutarti a memorizzare nella cache le immagini richieste in modo da non dover passare attraverso il lavoro di rigenerazione ogni volta che un utente desidera rivedere un particolare grafico.

Answer 8

  

Ho anche sentito che < form method = " get " > equivale completamente a inserire i parametri in un URL?

È vero, ecco la corrispondente sezione RFC

  

Esiste una lunghezza massima per una richiesta?

Le spec dice " HTTP il protocollo non pone alcun limite a priori sulla lunghezza di un URI. "

Tuttavia Internet Explorer 6 ha un limite di 2.083 caratteri. Altri browser consentono più personaggi ma se segui questa strada dovrai fondamentalmente progettare per ie6