Sự khác biệt cơ bản giữa METHOD="GET" và METHOD="POST" là chúng tương ứng với các yêu cầu HTTP khác nhau, như được định nghĩa trong HTTP. Quá trình gửi cho cả hai phương thức bắt đầu theo cùng một cách - a được trình duyệt xây dựng và sau đó được mã hóa theo cách được chỉ định bởi thuộc tính enctype. Đối với METHOD="POST, thuộc tính mã hóa có thể là nhiều phần/biểu mẫu dữ liệu hoặc ứng dụng/x-www-form-urlencoding, trong khi đối với METHOD="GET", chỉ cho phép ứng dụng/x-www-form-urlencoding. Tập dữ liệu biểu mẫu này sau đó được truyền đến máy chủ
Để gửi biểu mẫu bằng METHOD="GET", trình duyệt sẽ tạo một URL bằng cách lấy giá trị của thuộc tính hành động, nối thêm ? . Sau đó, trình duyệt xử lý URL này như thể theo một liên kết [hoặc như thể người dùng đã nhập trực tiếp URL]. Trình duyệt chia URL thành các phần và nhận ra một máy chủ, sau đó gửi tới máy chủ đó một yêu cầu GET với phần còn lại của URL làm đối số. Máy chủ lấy nó từ đó. Lưu ý rằng quy trình này có nghĩa là dữ liệu biểu mẫu được giới hạn ở mã ASCII. Cần đặc biệt cẩn thận để mã hóa và giải mã các loại ký tự khác khi chuyển chúng qua URL ở định dạng ASCII
Việc gửi biểu mẫu có METHOD="POST" khiến yêu cầu POST được gửi, sử dụng giá trị của thuộc tính hành động và thông báo được tạo theo loại nội dung được chỉ định bởi thuộc tính enctype
Ưu và nhược điểm
Vì dữ liệu biểu mẫu được gửi như một phần của URL khi GET được sử dụng --
- Dữ liệu biểu mẫu được giới hạn ở mã ASCII. Cần đặc biệt cẩn thận để mã hóa và giải mã các loại ký tự khác khi chuyển chúng qua URL ở định dạng ASCII. Mặt khác, dữ liệu nhị phân, hình ảnh và các tệp khác đều có thể được gửi thông qua METHOD="POST"
- Tất cả dữ liệu biểu mẫu đã điền được hiển thị trong URL. Hơn nữa, nó còn được lưu trữ trong lịch sử/nhật ký duyệt web của người dùng cho trình duyệt. Những sự cố này làm cho GET kém an toàn hơn
- Tuy nhiên, một lợi thế của dữ liệu biểu mẫu được gửi như một phần của URL là người ta có thể đánh dấu các URL và trực tiếp sử dụng chúng và bỏ qua hoàn toàn quy trình điền biểu mẫu
- Có giới hạn về lượng dữ liệu biểu mẫu có thể được gửi do độ dài URL bị giới hạn
- Script kiddies có thể dễ dàng vạch trần các lỗ hổng trong hệ thống để hack nó. Ví dụ: Citibank bị hack do thay đổi số tài khoản trong chuỗi URL. [1] Tất nhiên, các tin tặc hoặc nhà phát triển web có kinh nghiệm có thể để lộ các lỗ hổng như vậy ngay cả khi POST được sử dụng; . Nói chung, máy chủ phải nghi ngờ bất kỳ dữ liệu nào do máy khách gửi và đề phòng các Tham chiếu đối tượng trực tiếp không an toàn
Sự khác biệt trong xử lý phía máy chủ
Về nguyên tắc, việc xử lý dữ liệu biểu mẫu đã gửi phụ thuộc vào việc nó được gửi bằng METHOD="GET" hay METHOD="POST". Do dữ liệu được mã hóa theo nhiều cách khác nhau nên cần có các cơ chế giải mã khác nhau. Do đó, nói chung, việc thay đổi PHƯƠNG PHÁP có thể cần phải thay đổi tập lệnh xử lý việc gửi. Ví dụ: khi sử dụng giao diện CGI, tập lệnh sẽ nhận dữ liệu trong biến môi trường [QUERYSTRING] khi GET được sử dụng. Nhưng khi POST được sử dụng, dữ liệu biểu mẫu được truyền vào luồng đầu vào tiêu chuẩn [stdin] và số byte cần đọc được cung cấp bởi tiêu đề Độ dài nội dung
Điều gì xảy ra khi các biến GET và POST xung đột?
Trong một số ngôn ngữ như PHP, thông tin từ các tham số GET và POST, ngoài việc có sẵn một cách riêng lẻ, còn được kết hợp thành một biến tiện lợi e. g. , $_REQUEST trong PHP. Nếu có xung đột—tôi. e. , cùng một tên tham số được sử dụng với các giá trị khác nhau trong GET và POST—sau đó xung đột được giải quyết bằng các quy tắc nhất định. Trong trường hợp của PHP, quyền ưu tiên được quyết định bởi chỉ thị cấu hình. Thứ tự mặc định là EGPCS [môi trường, GET, POST, Cookie, Server]. Điều này có nghĩa là biến trong $_GET được ưu tiên hơn $_POST, do đó biến này được ưu tiên hơn $_COOKIE
Cách sử dụng được đề xuất
GET được khuyến nghị khi gửi các biểu mẫu "bình thường" - những biểu mẫu không 'làm thay đổi đáng kể trạng thái của thế giới'. Nói cách khác, các biểu mẫu chỉ liên quan đến truy vấn cơ sở dữ liệu. Một quan điểm khác là một số truy vấn tạm thời sẽ có tác dụng tương tự như một truy vấn đơn lẻ. Nếu có liên quan đến cập nhật cơ sở dữ liệu hoặc các hành động khác như kích hoạt email, thì nên sử dụng POST
Từ blog nhà phát triển Dropbox
trình duyệt không biết chính xác chức năng của một biểu mẫu HTML cụ thể, nhưng nếu biểu mẫu được gửi qua HTTP GET, thì trình duyệt sẽ biết rằng sẽ an toàn để tự động thử gửi lại nếu có lỗi mạng. Đối với các biểu mẫu sử dụng HTTP POST, việc thử lại có thể không an toàn nên trình duyệt sẽ yêu cầu người dùng xác nhận trước
Yêu cầu "NHẬN" thường được lưu vào bộ đệm, trong khi yêu cầu "POST" khó có thể được. Đối với các hệ thống truy vấn, điều này có thể có tác động hiệu quả đáng kể, đặc biệt nếu các chuỗi truy vấn đơn giản, vì các bộ đệm có thể phục vụ các truy vấn thường xuyên nhất
Trong một số trường hợp nhất định, nên sử dụng POST ngay cả đối với các truy vấn bình thường
- Nếu dữ liệu biểu mẫu chứa các ký tự không phải ASCII [chẳng hạn như các ký tự có dấu], thì về nguyên tắc, METHOD="GET" không thể áp dụng được, mặc dù nó có thể hoạt động trong thực tế [chủ yếu cho ]
- Nếu tập dữ liệu biểu mẫu lớn - giả sử, hàng trăm ký tự - thì METHOD="GET" có thể gây ra sự cố thực tế với việc triển khai không thể xử lý các URL dài đó
- Bạn có thể muốn tránh METHOD="GET" để làm cho người dùng ít nhìn thấy biểu mẫu hoạt động hơn, đặc biệt là để làm cho các trường "ẩn" [INPUT TYPE="HIDDEN"] ẩn hơn bằng cách không xuất hiện trong URL. Nhưng ngay cả khi bạn sử dụng các trường ẩn với METHOD="POST", chúng vẫn sẽ xuất hiện trong mã nguồn HTML
Còn HTTPS thì sao?
Cập nhật ngày 15 tháng 5 năm 2015. Cụ thể là khi sử dụng HTTPS [HTTP qua TLS/SSL], POST có cung cấp bảo mật nào cao hơn GET không?
Đây là một câu hỏi thú vị. Giả sử bạn thực hiện một yêu cầu GET tới một trang web
GET //www.example.com/login.php?user=mickey&passwd=mini
Giả sử rằng kết nối Internet của bạn đang bị theo dõi, thông tin nào về yêu cầu này sẽ có sẵn cho kẻ rình mò?
Câu trả lời là không. Nếu bạn thực hiện một yêu cầu GET như vậy, kẻ tấn công sẽ chỉ biết những thông tin sau khi theo dõi lưu lượng truy cập web của bạn
- Thực tế là bạn đã thực hiện kết nối HTTPS
- Tên máy chủ - www. thí dụ. com
- Tổng chiều dài của yêu cầu
- Độ dài của câu trả lời
Phần đường dẫn của URL — tôi. e. , trang thực tế được yêu cầu, cũng như các tham số chuỗi truy vấn — được bảo vệ [được mã hóa] khi chúng "qua dây" i. e. , đang trên đường đến máy chủ đích. Tình hình hoàn toàn giống với các yêu cầu POST
Tuy nhiên, phương thức POST vẫn giữ được một lợi thế ngay cả trong trường hợp HTTPS. Các máy chủ web có xu hướng ghi lại toàn bộ URL được yêu cầu ở dạng văn bản thuần túy trong nhật ký truy cập của chúng; . Điều này áp dụng bất kể HTTP hay HTTPS được sử dụng