GET vs POST

HTTP POST permintaan membekalkan data tambahan dari klien (penyemak imbas) ke pelayan dalam badan mesej. Berbeza, GET permintaan termasuk semua data yang diperlukan dalam URL. Bentuk dalam HTML boleh menggunakan salah satu kaedah dengan menentukan kaedah = "POST" atau kaedah = "GET" (lalai) dalam elemen. Kaedah yang ditentukan menentukan bagaimana data borang dihantar ke pelayan. Apabila kaedah GET, semua data borang dikodkan ke URL, ditambahkan kepada tindakan URL sebagai parameter rentetan pertanyaan. Dengan POST, data bentuk muncul dalam badan mesej permintaan HTTP.

Carta perbandingan

GET berbanding carta perbandingan POST

	GET	POST

Sejarah	Parameter kekal dalam sejarah pelayar kerana ia adalah sebahagian daripada URL	Parameter tidak disimpan dalam sejarah penyemak imbas.
Telah ditandakan	Boleh dijadikan bookmark.	Tidak boleh ditandakan.
Butang BACK / tunduk semula tingkah laku	Permintaan GET dilaksanakan semula tetapi mungkin tidak diserahkan semula ke pelayan jika HTML disimpan dalam cache penyemak imbas.	Pelayar biasanya memberi amaran kepada pengguna bahawa data perlu dihantar semula.
Jenis pengekodan (atribut enctype)	permohonan / x-www-form-urlencoded	data multipart / borang atau aplikasi / x-www-form-urlencoded Gunakan pengekodan berbilang untuk data binari.
Parameter	boleh menghantar tetapi data parameter adalah terhad kepada apa yang boleh kita masukkan ke dalam baris permintaan (URL). Terus menggunakan kurang daripada 2K parameter, sesetengah pelayan mengendalikan sehingga 64K	Boleh menghantar parameter, termasuk memuat naik fail, ke pelayan.
Digodam	Lebih mudah untuk menggodam skrip kiddies	Lebih sukar untuk hack
Sekatan ke atas jenis data borang	Ya, hanya aksara ASCII yang dibenarkan.	Tiada sekatan. Data perduaan juga dibenarkan.
Keselamatan	GET kurang selamat berbanding POST kerana data yang dihantar adalah sebahagian daripada URL. Jadi ia disimpan dalam sejarah penyemak imbas dan log pelayan dalam plaintext.	POST sedikit lebih selamat daripada GET kerana parameter tidak disimpan dalam sejarah penyemak imbas atau dalam log pelayan web.
Sekatan ke atas panjang data borang	Ya, kerana data bentuk dalam URL dan panjang URL adalah terhad. Had panjang URL yang selamat seringkali mengandungi 2048 aksara tetapi berbeza dengan penyemak imbas dan pelayan web.	Tiada sekatan
Kebolehgunaan	Kaedah GET tidak boleh digunakan apabila menghantar kata laluan atau maklumat sensitif yang lain.	Kaedah POST yang digunakan semasa menghantar kata laluan atau maklumat sensitif yang lain.
Keterlihatan	Kaedah GET boleh dilihat oleh semua orang (ia akan dipaparkan dalam bar alamat penyemak imbas) dan mempunyai had jumlah maklumat untuk dihantar.	Pembolehubah kaedah POST tidak dipaparkan dalam URL.
Cached	Boleh cache	Tidak cache

Kandungan: GET vs POST

1 Perbezaan dalam Penyerahan Borang
- 1.1 Kebaikan dan Kekurangan
2 Perbezaan dalam Pemprosesan Side Server
3 Penggunaan yang Disyorkan
4 Bagaimana dengan HTTPS?
5 Rujukan

Perbezaan dalam Penyerahan Borang

Perbezaan asas antara METODE = "GET" dan KAEDAH = "POST" adalah bahawa mereka sesuai dengan permintaan HTTP yang berlainan, seperti yang ditakrifkan dalam spesifikasi HTTP. Proses penyerahan untuk kedua-dua kaedah bermula dengan cara yang sama - set data bentuk dibina oleh penyemak imbas dan kemudian dikodkan dengan cara yang ditentukan oleh enctype atribut. Untuk KAEDAH = "POST yang enctype atribut boleh berbilang / data bentuk atau permohonan / x-www-form-urlencoded, sedangkan untuk METODE = "GET", sahaja permohonan / x-www-form-urlencoded dibenarkan. Set data borang ini kemudiannya dihantar ke pelayan.

Untuk penyerahan borang dengan METODE = "GET", pelayar membina URL dengan mengambil nilai dari tindakan atribut, tambah a ? untuk itu, kemudian menambah set data borang (dikodkan menggunakan jenis aplikasi / x-www-bentuk-url dikodkan semula). Penyemak imbas kemudian memproses URL ini seolah-olah mengikuti pautan (atau seolah-olah pengguna telah menaip URL secara langsung). Pelayar membahagikan URL ke bahagian dan mengiktiraf tuan rumah, kemudian menghantar kepada tuan rumah permintaan GET dengan seluruh URL sebagai hujah. Pelayan mengambilnya dari sana. Ambil perhatian bahawa proses ini bermaksud bahawa data bentuk adalah terhad kepada kod ASCII. Penjagaan khas harus diambil untuk mengekod dan menyusun semula jenis watak lain apabila menyampaikannya melalui URL dalam format ASCII.

Penyerahan borang dengan METODE = "POST" menyebabkan permintaan POST dihantar, menggunakan nilai tindakan atribut dan mesej yang dibuat mengikut jenis kandungan yang ditentukan oleh enctype atribut.

Kebaikan dan keburukan

Oleh kerana data borang dihantar sebagai sebahagian daripada URL apabila GET digunakan --

Data borang dihadkan kepada kod ASCII. Penjagaan khas harus diambil untuk mengekod dan menyusun semula jenis watak lain apabila menyampaikannya melalui URL dalam format ASCII. Sebaliknya, data binari, imej dan fail lain boleh dihantar melalui KAEDAH = "POST"
Semua data borang diisi masuk dalam URL. Selain itu, ia juga disimpan di dalam sejarah penyemakan imbas web / log pengguna untuk penyemak imbas. Isu-isu ini membuat GET kurang selamat.
Walau bagaimanapun, satu kelebihan data borang yang dihantar sebagai sebahagian daripada URL adalah bahawa seseorang boleh menanda URL dan terus menggunakannya dan sepenuhnya memintas proses pengisian borang.
Terdapat had ke atas berapa banyak data borang boleh dihantar kerana panjang URL adalah terhad.
Kiddies skrip boleh dengan mudah memperlihatkan kelemahan dalam sistem untuk menggodamnya. Sebagai contoh, Citibank digodam dengan mengubah nombor akaun dalam rentetan URL.^[1] Sudah tentu, penggodam yang berpengalaman atau pemaju web boleh mendedahkan kelemahan tersebut walaupun POST digunakan; ia hanya sedikit lebih sukar. Secara umum, pelayan harus mencurigai data yang dihantar oleh klien dan pengawal terhadap Rujukan Objek Langsung Langsung.

Perbezaan dalam Pemprosesan Side Server

Pada dasarnya, pemprosesan data borang yang dihantar bergantung kepada sama ada ia dihantar dengan METODE = "GET" atau KAEDAH = "POST". Oleh kerana data dikodkan dalam pelbagai cara, mekanisme penyahkodan yang berbeza diperlukan. Oleh itu, secara amnya, mengubah KAEDAH mungkin memerlukan perubahan skrip yang memproses penyerahan. Sebagai contoh, apabila menggunakan antara muka CGI, skrip menerima data dalam pembolehubah persekitaran (QUERYSTRING) apabila GET digunakan. Tetapi apabila POST digunakan, data bentuk diluluskan dalam strim input standardstdin) dan bilangan bait untuk dibaca diberikan oleh tajuk panjang Kandungan.

Penggunaan yang Disyorkan

GET disyorkan apabila menyerahkan borang "idempotent" - yang tidak 'mengubah keadaan dunia dengan ketara'. Dengan kata lain, bentuk yang melibatkan pertanyaan pangkalan data sahaja. Perspektif lain ialah beberapa pertanyaan idempotent akan mempunyai kesan yang sama seperti pertanyaan tunggal. Sekiranya kemas kini pangkalan data atau tindakan lain seperti mencetuskan e-mel terlibat, penggunaan POST adalah disyorkan.

Dari blog pemaju Dropbox:

pelayar tidak tahu apa bentuk HTML tertentu, tetapi jika borang diserahkan melalui HTTP GET, penyemak imbas tahu selamat untuk mencuba semula secara automatik jika terdapat ralat rangkaian. Untuk borang yang menggunakan HTTP POST, ia mungkin tidak selamat untuk mencuba supaya penyemak imbas meminta pengguna untuk pengesahan terlebih dahulu.

Permintaan "GET" sering dikosongkan, sedangkan permintaan "POST" tidak boleh. Untuk sistem pertanyaan, ini mungkin mempunyai kesan kecekapan yang besar, terutamanya jika rentetan pertanyaan adalah mudah, kerana cache mungkin melayani pertanyaan yang paling sering.

Dalam kes tertentu, menggunakan POST disyorkan walaupun untuk pertanyaan idempotent:

Jika data borang mengandungi aksara bukan ASCII (seperti aksara beraksen), kemudian METODE = "GET" tidak dapat digunakan secara prinsip, walaupun ia mungkin berfungsi dalam praktik (terutamanya untuk aksara ISO Latin 1).
Sekiranya set data borang besar - katakan, ratusan watak - maka METODE = "GET" boleh menyebabkan masalah praktikal dengan pelaksanaan yang tidak dapat menangani URL lama itu.
Anda mungkin ingin mengelak METODE = "GET" untuk menjadikannya kurang kelihatan kepada pengguna bagaimana borang berfungsi, terutamanya untuk membuat medan "tersembunyi" (INPUT TYPE = "HIDDEN") lebih tersembunyi dengan tidak muncul di URL. Tetapi walaupun anda menggunakan medan tersembunyi dengan KAEDAH = "POST", mereka masih akan muncul dalam kod sumber HTML.

Bagaimana pula dengan HTTPS?

Dikemaskini 15 Mei 2015: Khususnya apabila menggunakan HTTPS (HTTP lebih dari TLS / SSL), apakah POST menawarkan keselamatan lebih daripada GET?

Ini adalah soalan yang menarik. Katakan anda membuat permintaan GET ke laman web:

 GET https://www.example.com/login.php?user=mickey&passwd=mini

Dengan mengandaikan bahawa sambungan Internet anda sedang dipantau, apakah maklumat mengenai permintaan ini akan tersedia kepada pengintip? Sekiranya POST digunakan, dan pengguna dan data passwd disertakan dalam pemboleh ubah POST, akan lebih selamat dalam hal sambungan HTTPS?

Jawapannya adalah tidak. Sekiranya anda membuat permintaan GET, hanya maklumat berikut akan diketahui oleh penyerang yang memantau lalu lintas web anda:

Hakikat bahawa anda membuat sambungan HTTPS
Nama hos - www.example.com
Jumlah keseluruhan permintaan
Tempoh tindak balas

Bahagian jalan URL - iaitu, halaman sebenar yang diminta, serta parameter rentetan pertanyaan - dilindungi (disulitkan) semasa mereka "melalui dawai" iaitu, dalam perjalanan dalam perjalanan ke pelayan destinasi. Keadaan ini adalah sama untuk permintaan POST.

Sudah tentu, pelayan web cenderung untuk log seluruh URL dalam teks biasa dalam log akses mereka; jadi menghantar maklumat sensitif ke atas GET bukan idea yang baik. Ini terpakai tanpa mengira sama ada HTTP atau HTTPS digunakan.

Rujukan

wikipedia: POST (HTTP)
Kaedah Permintaan HTTP
Post HTTP - W3.org
Dapatkan HTTP - W3.org
Adakah HTTPS menyembunyikan URL yang diakses? - Stack Exchange

Teknologi