Perché non ci sono metodi PUT e DELETE sui moduli HTML?

HTML4 / XHTML1 consente solo GET e POST nei moduli, ora sembra che HTML5 farà lo stesso. C'è una proposta per aggiungere questi due, ma non sembra guadagnare terreno. Quali sono stati i motivi tecnici o politici per non includere PUT e DELETE nella bozza delle specifiche HTML5?

Questa è una domanda affascinante. Le altre risposte qui sono tutte speculative e in alcuni casi completamente errate. Invece di scrivere la mia opinione qui, in realtà ho fatto alcune ricerche e ho trovato fonti originali che discutono del perché eliminare e mettere non fanno parte del modulo standard HTML5.

A quanto pare, questi metodi sono stati inclusi in diverse prime bozze HTML5 (!), Ma sono stati successivamente rimossi nelle bozze successive . Mozilla lo aveva effettivamente implementato anche in una beta di Firefox .

Qual è stata la logica per la rimozione di questi metodi dalla bozza? Il W3C ha discusso questo argomento nella segnalazione bug 10671 . Mike Amundsen ha sostenuto questo sostegno:

L'esecuzione di PUT e DELETE per modificare le risorse sul server di origine è semplice per i moderni browser Web che utilizzano l'oggetto XmlHttpRequest. Per le interazioni del browser senza script questo non è così semplice. [...]

Questo modello è richiesto così spesso che numerosi framework / librerie Web di uso comune hanno creato una soluzione "integrata". [...]

Altre considerazioni:

• L'uso di POST come tunnel anziché utilizzare PUT / DELETE può portare a errori di corrispondenza nella cache (ad es. Le risposte POST sono memorizzabili , le risposte PUT no (6), le risposte DELETE no (7))
• L'uso di un metodo non idempotente (POST) per eseguire un'operazione idempotente (PUT / DELETE) complica il recupero a causa di guasti della rete (ad es. "È sicuro ripetere questa azione?").
• [...]

Vale la pena di leggere l'intero suo post.

Tom Wardrop fa anche un punto interessante:

L'HTML è indissolubilmente legato all'HTTP. HTML è l'interfaccia umana di HTTP. È quindi automaticamente discutibile il motivo per cui HTML non supporta tutti i metodi pertinenti nella specifica HTTP. Perché le macchine possono METTERE e ELIMINARE le risorse, ma gli umani non possono? [...]

È contraddittorio che, sebbene l'HTML faccia di tutto per garantire il markup semantico, finora non ha fatto alcuno sforzo per garantire richieste HTTP semantiche.

Il bug alla fine fu chiuso come Won't Fix da Ian Hickson, con la seguente logica:

PUT come metodo di form non ha senso, non si vorrebbe mettere un payload di form. DELETE ha senso solo se non c'è payload, quindi non ha molto senso neanche con i moduli.

Tuttavia, questa non è la fine della storia! Il problema è stato chiuso nel bug tracker W3C ed è stato convertito nel tracker dei problemi del gruppo di lavoro HTML:

https://www.w3.org/html/wg/tracker/issues/195

A questo punto, sembra che il motivo principale per cui non esiste alcun supporto per questi metodi sia semplicemente che nessuno si è preso il tempo di scrivere una specifica completa per questo.

GET e POST hanno una chiara logica neutrale per il contenuto. OTTENERE è recuperare il contenuto di un URL in modo sicuro da ripetere e possibilmente cache. POST è fare qualcosa in un modo che non è sicuro ripetere, eseguire in modo speculativo o cache.

Non c'era una logica simile per PUT o DELETE. Entrambi sono completamente coperti da POST. La creazione o la distruzione di una risorsa sono operazioni non sicure da ripetere, non sicure da eseguire in modo speculativo e che non devono essere memorizzate nella cache. Non sono necessarie ulteriori semantiche speciali per loro.

Quindi sostanzialmente non ci sono benefici.

Questo è stato sollevato nel 2010 poiché Bug 10671 considera l'aggiunta del supporto per PUT e DELETE come metodi di form .

C'è stata una moderata quantità di respingimenti per questa "caratteristica" e un po 'di pesantezza, ma alla fine questo è stato intensificato come due problemi sul tracker dei bug dei gruppi di lavoro:

• EMISSIONE 195: migliora la generazione di richieste http dai moduli
• NUMERO 196: Definire il comportamento di gestione della risposta http dell'agente utente

Il problema ISSUE-196 ha comportato una decisione di consenso per non apportare modifiche alla specifica poiché la specifica HTML attualmente non limita il modo in cui vengono gestite le risposte alle richieste POST. Credo che questo particolare problema sia stato sollevato nel tentativo di riconciliare i pattern di reindirizzamento POST comunemente utilizzati e in che modo i server ReSTful forniscono spesso risposte 2xx con messaggi brevi anziché qualcosa di utile da visualizzare in un browser.

Il numero ISSUE-195 è stato presentato alle sedie. Cameron Jones si è fatto volontario per scrivere una proposta di modifica il 18 gennaio 2012 che ha presentato per diventare la prima bozza di lavoro il 29 maggio 2014. La bozza passerà attraverso il processo di raccomandazioni del W3C .

Con un po 'di fortuna, questo diventerà presto una raccomandazione del W3C e implementata dai fornitori di browser, e sarebbe un grande passo avanti nella rimozione dei blocchi per produrre servizi ReSTful unificati, semantici e compatibili con i browser. Immagino che ciò susciterà un'interessante evoluzione nei modelli di servizio. Jon Moore parla bene : vale la pena guardare le API di Hypermedia , questo ha suscitato il mio interesse ma è caduto al primo ostacolo (questo).

La mia comprensione è che i browser non sanno cosa fare dopo aver inviato un PUT o un DELETE. Un POST reindirizza di solito a una pagina appropriata, ma PUT e DELETE in genere no. Ciò li rende appropriati per le chiamate tramite Ajax o un programma nativo, ma non da un modulo browser web.

Non riesco a impedirlo in questo momento, ma ricordo di aver letto una delle mailing list html5 quando ne stavano discutendo.

Storia

Penso che valga la pena menzionare la prima apparizione dei moduli html nella RFC1866 (Sezione 8.1) . Qui l'attributo del metodo è definito come il seguente:

METHOD
        selects a method of accessing the action URI. The set of
        applicable methods is a function of the scheme of the
        action URI of the form. See 8.2.2, "Query Forms:
        METHOD=GET" and 8.2.3, "Forms with Side-Effects:
        METHOD=POST".

Ulteriori spiegazioni si trovano nella Sezione 8.2.2 - GET e nella Sezione 8.2.3 - POST

Tieni presente che HTML 2.0 (novembre 1995) è stato specificato prima di HTTP 1.0 (maggio 1996). Quindi tutti hanno usato HTTP solo con GET (a partire da HTTP 0.9) o con l'estensione POST. Ma solo pochi server Web supportano PUT e DELETE (come indicato nell'Appendice HTTP 1.0 ).

Pensieri

Se pensate a come potrebbe essersi evoluto lo sviluppo della rete semantica di Berners-Lee, sembra chiaro che è passato da problemi reali a un concetto generale. Prima voleva condividere documenti. Pertanto aveva bisogno del markup. Quindi voleva interrogare i database per il contenuto, quindi aveva bisogno di moduli. Quindi ha voluto inserire nuovi dati nel database. Quindi ha usato le forme con GET e POST. Dopodiché potrebbe aver capito che era possibile eseguire tutte le operazioni CRUD sui dati da remoto, quindi HTTP è stato esteso ma mai HTML perché era troppo tardi (solo pochi server supportavano le nuove operazioni CRUD).

Basta fare un'ipotesi selvaggia, ma probabilmente perché HTTP non è terribilmente buono con il controllo degli accessi nel migliore dei casi, e l'ultima cosa di cui tutti hanno bisogno sono ancora più modi per URL dannosi di compromettere un sito Web e / o un'applicazione scarsamente protetti.

HTTP non è in realtà un buon protocollo per i trasferimenti di file oltre al download dal server al client. Usa FTP - o meglio ancora, SFTP.

Ottieni e pubblica sono formati di trasmissione dei dati della richiesta.

Suppongo che tu stia chiedendo di inviare un modulo in un servizio RESTFUL. Ma non ha senso cambiare lo standard della richiesta http per fare delle ipotesi lo scopo della richiesta http. Le informazioni sullo scopo che la richiesta riempie sono gestite al meglio nei campi di input.

Avere un indirizzo, ottenere e pubblicare consente al server di interpretare la richiesta e i relativi valori di input correttamente. Da lì i valori di input consentono di effettuare richieste aperte al server e di fare ciò che si desidera. Ad esempio, puoi avere un campo i cui valori sono "put" ed "delete"