Pertanyaan Bagaimana parameter dikirim dalam permintaan HTTP POST?


Di HTTP MENDAPATKAN permintaan, parameter dikirim sebagai a string kueri:

http://example.com/page? parameter = nilai & juga = lainnya

Di HTTP POS permintaan, parameter tidak dikirim bersama dengan URI.

Di mana nilainya? Di tajuk permintaan? Di badan permintaan? Seperti apa bentuknya?


1165
2018-01-27 19:19


asal


Jawaban:


Nilai dikirim dalam isi permintaan, dalam format yang ditentukan oleh tipe konten.

Biasanya tipe kontennya application/x-www-form-urlencoded, sehingga badan permintaan menggunakan format yang sama dengan string kueri:

parameter=value&also=another

Saat Anda menggunakan unggahan file dalam formulir, Anda menggunakan multipart/form-data encoding sebagai gantinya, yang memiliki format berbeda. Ini lebih rumit, tetapi Anda biasanya tidak perlu peduli seperti apa bentuknya, jadi saya tidak akan menunjukkan contoh, tetapi bisa baik untuk mengetahui bahwa itu ada.


962
2018-01-27 19:32



Konten diletakkan setelah header HTTP. Format HTTP POST adalah memiliki header HTTP, diikuti dengan garis kosong, diikuti oleh body permintaan. Variabel POST disimpan sebagai pasangan nilai kunci dalam tubuh.

Anda dapat melihat ini di konten mentah dari Pos HTTP, ditampilkan di bawah ini:

POST /path/script.cgi HTTP/1.0
From: frog@jmarshall.com
User-Agent: HTTPTool/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 32

home=Cosby&favorite+flavor=flies

Anda dapat melihat ini menggunakan alat seperti Pemain biola, yang dapat Anda gunakan untuk menonton permintaan HTTP mentah dan payload respons yang dikirim melintasi kabel.


349
2018-01-27 19:21



Jawaban singkat: dalam permintaan POST, nilai dikirim dalam "badan" permintaan. Dengan formulir web, kemungkinan besar mereka dikirim dengan jenis media application/x-www-form-urlencoded atau multipart/form-data. Bahasa pemrograman atau kerangka kerja yang telah dirancang untuk menangani permintaan-web biasanya melakukan "Hal yang Benar" dengan permintaan tersebut dan memberi Anda akses mudah ke nilai yang telah diterjemahkan (seperti $_REQUEST atau $_POST di PHP, atau cgi.FieldStorage(), flask.request.form dengan Python).


Sekarang mari kita sedikit menyimpang, yang dapat membantu memahami perbedaannya;)

Perbedaan antara GET dan POST permintaan sebagian besar bersifat semantik. Mereka juga "digunakan" berbeda, yang menjelaskan perbedaan dalam bagaimana nilai-nilai dilewatkan.

DAPATKANbagian RFC yang relevan)

Saat mengeksekusi GET meminta, Anda meminta server untuk satu, atau satu set entitas. Agar klien dapat memfilter hasil, dapat menggunakan "string kueri" yang disebut dari URL. String kueri adalah bagian setelah ?. Ini adalah bagian dari URI sintaksis.

Jadi, dari sudut pandang kode aplikasi Anda (bagian yang terima permintaan), Anda perlu memeriksa bagian kueri URI untuk mendapatkan akses ke nilai-nilai ini.

Perhatikan bahwa kunci dan nilai adalah bagian dari URI. Browser mungkin menerapkan batas pada panjang URI. Standar HTTP menyatakan bahwa tidak ada batasan. Tetapi pada saat penulisan ini, sebagian besar browser melakukan batasi URI (saya tidak memiliki nilai tertentu). GET permintaan seharusnya tak pernah digunakan untuk mengirimkan informasi baru ke server. Terutama bukan dokumen yang lebih besar. Di situlah Anda harus menggunakannya POST atau PUT.

POST (bagian RFC yang relevan)

Saat mengeksekusi POST permintaan, klien sebenarnya mengirimkan yang baru dokumen ke host jarak jauh. Jadi, a pertanyaan string tidak (semantis) masuk akal. Itulah mengapa Anda tidak memiliki akses ke mereka dalam kode aplikasi Anda.

POST sedikit lebih rumit (dan cara lebih fleksibel):

Saat menerima permintaan POST, Anda harus selalu mengharapkan "payload", atau, dalam istilah HTTP: a Badan Pesan. Tubuh pesan itu sendiri sangat tidak berguna, karena tidak ada standar (sejauh yang saya tahu. Mungkin aplikasi / octet-stream?) format. Format tubuh ditentukan oleh Content-Type tajuk. Saat menggunakan HTML FORM elemen dengan method="POST", ini biasanya application/x-www-form-urlencoded. Tipe lain yang sangat umum adalah multipart / form-data jika Anda menggunakan unggahan file. Tapi bisa jadi apa pun, mulai dari text/plain, lebih application/json atau bahkan kebiasaan application/octet-stream.

Dalam hal apapun, jika a POST permintaan dibuat dengan Content-Type yang tidak dapat ditangani oleh aplikasi, seharusnya mengembalikan a 415 Kode status.

Sebagian besar bahasa pemrograman (dan / atau kerangka-web) menawarkan cara untuk membatalkan / meng-enkode isi pesan dari / ke jenis yang paling umum (seperti application/x-www-form-urlencoded, multipart/form-data atau application/json). Jadi itu mudah. Tipe khusus membutuhkan kerja yang sedikit lebih potensial.

Menggunakan formulir standar HTML yang dienkode sebagai contoh, aplikasi harus melakukan langkah-langkah berikut:

  1. Membaca Content-Type bidang
  2. Jika nilainya bukan salah satu jenis media yang didukung, maka kembalikan tanggapan dengan a 415 Kode status
  3. jika tidak, decode nilai dari isi pesan.

Sekali lagi, bahasa seperti PHP, atau kerangka web untuk bahasa populer lainnya mungkin akan menangani ini untuk Anda. Pengecualian untuk ini adalah 415 kesalahan. Tidak ada kerangka kerja yang dapat memprediksi jenis konten mana yang dipilih oleh aplikasi Anda untuk mendukung dan / atau tidak mendukung. Ini terserah kamu.

TARUH (bagian RFC yang relevan)

SEBUAH PUT permintaan cukup banyak ditangani dengan cara yang sama persis seperti POST permintaan. Perbedaan besar adalah bahwa a POST permintaan seharusnya membiarkan server memutuskan bagaimana (dan jika sama sekali) membuat sumber daya baru. Secara historis (dari RFC2616 yang sekarang sudah usang itu adalah untuk menciptakan sumber daya baru sebagai "bawahan" (anak) dari URI di mana permintaan itu dikirim ke).

SEBUAH PUT permintaan sebaliknya seharusnya "menyimpan" sumber daya secara tepat di URI itu, dan dengan persis konten itu. Tidak lebih, tidak kurang. Idenya adalah bahwa klien bertanggung jawab untuk membuat lengkap sumber daya sebelum "PUTting" itu. Server harus menerimanya dengan adanya pada URL yang diberikan.

Sebagai akibatnya, a POST permintaan biasanya tidak digunakan menggantikan sumber daya yang ada. SEBUAH PUT permintaan dapat melakukan keduanya buat dan menggantikan.

Catatan Samping

Ada juga "parameter jalur"yang dapat digunakan untuk mengirim data tambahan ke remote, tetapi mereka sangat jarang, bahwa saya tidak akan terlalu banyak detail di sini. Tapi, untuk referensi, di sini adalah kutipan dari RFC:

Selain dari titik-segmen dalam jalur hierarkis, segmen jalan dianggap   buram dengan sintaks generik. Aplikasi penghasil URI sering menggunakan   karakter yang dicadangkan diizinkan dalam segmen untuk membatasi spesifik skema atau   subkomponen khusus dereference-handler. Misalnya, titik koma (";")   dan equals ("=") karakter yang dicadangkan sering digunakan untuk membatasi parameter dan   nilai parameter yang berlaku untuk segmen itu. Koma (",") dilindungi   karakter sering digunakan untuk tujuan serupa. Misalnya, satu produser URI   mungkin menggunakan segmen seperti "nama; v = 1.1" untuk menunjukkan referensi ke versi   1,1 dari "nama", sedangkan yang lain mungkin menggunakan segmen seperti "nama, 1,1" untuk   menunjukkan hal yang sama. Jenis parameter dapat ditentukan oleh skema khusus   semantik, tetapi dalam banyak kasus sintaks parameter adalah khusus untuk   implementasi algoritma dereferencing URI.


287
2017-11-03 15:54



Anda tidak dapat mengetiknya langsung di bilah URL browser.

Anda dapat melihat bagaimana data POST dikirim di Internet dengan Header HTTP Langsung sebagai contoh. Hasilnya akan menjadi sesuatu seperti itu

http://127.0.0.1/pass.php
POST /pass.php HTTP/1.1

Host: 127.0.0.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: http://127.0.0.1/pass.php
Cookie: passx=87e8af376bc9d9bfec2c7c0193e6af70; PHPSESSID=l9hk7mfh0ppqecg8gialak6gt5
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
username=zurfyx&pass=password

Di mana dikatakan

Content-Length: 30
    username=zurfyx&pass=password

akan menjadi nilai postingan.


48
2018-01-27 19:29



Jenis media default dalam permintaan POST adalah application/x-www-form-urlencoded. Ini adalah format untuk menyandikan pasangan nilai-kunci. Kunci dapat digandakan. Setiap pasangan nilai-kunci dipisahkan oleh & karakter, dan setiap kunci dipisahkan dari nilainya oleh suatu = karakter.

Sebagai contoh:

Name: John Smith
Grade: 19

Dikodekan sebagai:

Name=John+Smith&Grade=19

Ini ditempatkan di badan permintaan setelah header HTTP.


18
2018-06-16 05:33



Nilai formulir dalam HTTP POST dikirim dalam isi permintaan, dalam format yang sama dengan querystring.

Untuk informasi lebih lanjut, lihat spesifikasi.


13
2018-01-27 19:20



Beberapa layanan web mengharuskan Anda untuk mengajukan permintaan data dan metadata terpisah. Sebagai contoh, fungsi remote dapat mengharapkan bahwa string metadata yang ditandai dimasukkan dalam URI, sementara data diposkan di dalam tubuh HTTP.

Permintaan POST mungkin secara semantis terlihat seperti ini:

POST /?AuthId=YOURKEY&Action=WebServiceAction&Signature=rcLXfkPldrYm04 HTTP/1.1
Content-Type: text/tab-separated-values; charset=iso-8859-1
Content-Length: []
Host: webservices.domain.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: identity
User-Agent: Mozilla/3.0 (compatible; Indy Library)

name    id
John    G12N
Sarah   J87M
Bob     N33Y

Pendekatan ini secara logis menggabungkan QueryString dan Body-Post menggunakan single Content-Type yang merupakan "parsing-instruksi" untuk web-server.

Tolong dicatat: HTTP / 1.1 adalah dibungkus dengan #32 (ruang) di sebelah kiri dan dengan #10 (Pakan baris) di sebelah kanan.


13
2017-07-31 14:01



Pertama-tama, mari kita bedakan GET dan POST 

Mendapatkan: Ini adalah standarnya HTTP permintaan yang dibuat ke server dan digunakan untuk mengambil data dari server dan string kueri yang datang setelahnya ? di sebuah URI digunakan untuk mengambil sumber daya yang unik.

ini adalah formatnya

GET /someweb.asp?data=value HTTP/1.0

sini data=value adalah nilai string kueri berlalu.

POS: Ini digunakan untuk mengirim data ke server dengan aman sehingga apa pun yang dibutuhkan, ini adalah format a POST permintaan

POST /somweb.aspHTTP/1.0
Host: localhost
Content-Type: application/x-www-form-urlencoded //you can put any format here
Content-Length: 11 //it depends
Name= somename

Mengapa POST lebih dari GET?

Di GET nilai yang dikirim ke server biasanya ditambahkan ke URL dasar dalam string kueri, Ini membuat data Anda dapat diretas (ini adalah masalah kembali dalam beberapa hari untuk Facebook di mana kredensial Anda terkena) itulah sebabnya POSTdigunakan untuk mengirim data ke server yang digunakan Request Body untuk mengirim data Anda ke server yang lebih aman karena menyembunyikan data Anda ditambah data Anda dari bidang menghitung panjangnya dan menambahkannya ke header untuk content-length dan tidak ada data penting yang langsung ditambahkan ke URL

sekarang bahwa permintaan Anda dibuat aman setiap nilai yang dikirim ke server dapat dikirim dalam Request Body seperti namanya itu akan berisi data yang ingin dikirim pengguna (dan itu dikirim dalam URL Encoded format) dan Request Headers akan menjaga Permintaan aman dengan membandingkan nilai dalam Request Body dengan Request Headers

Anda dapat menggunakan bagian jaringan Alat Pengembang Google untuk melihat informasi dasar tentang bagaimana permintaan dibuat ke server.

dan Anda selalu dapat menambahkan lebih banyak nilai di Anda Request Headers seperti Cache-Control , Origin , Accept.


0
2017-07-19 07:04