2008-11-05 15 views
6

Bây giờ, tôi biết sự khác biệt giữa các tham số trong URL và thông số POST: một số trình duyệt có thể hoạt động sai nếu URL quá dài, do đó, không nên đưa hàng trăm tham số vào URL, ngay cả khi ứng dụng của bạn có thể trả lời yêu cầu GET.Có sự khác biệt nào giữa các tham số trong URL và <form method = "get"> không?

Vì mục đích thảo luận, hãy giả sử ứng dụng web sau: người dùng có thể nhập một loạt (có thể là hàng trăm) tọa độ X, Y. Máy chủ vẽ chúng trong một biểu đồ, được trả về dưới dạng hình ảnh.

Đây rõ ràng là ví dụ về số idempotent operation, vì vậy, theo số HTTP spec, bạn nên thực hiện như một thao tác GET. Tuy nhiên, bạn không thể xây dựng một URL với tất cả các tham số, vì nó sẽ quá dài. Phương thức biểu mẫu < = "get" > có xử lý nhiều tham số không?

Tôi cũng nghe nói rằng < phương thức biểu mẫu = "get" > hoàn toàn tương đương với việc đặt thông số trong URL? Bây giờ, điều đó có đúng với một số trình duyệt hoặc cho toàn bộ giao thức HTTP không? Có độ dài tối đa cho yêu cầu không?

Trả lời

7

Thông số HTTP không đặt giới hạn, nhưng trình duyệt và máy chủ thực hiện. Xem here để biết chi tiết cụ thể.

Trình duyệt sẽ tạo URL dài nếu phương thức được đặt thành GET cho một biểu mẫu, vì vậy các giới hạn ở trên sẽ được áp dụng.

2

Những gì trình duyệt của bạn thực sự làm là xây dựng một url thực sự dài từ đầu vào biểu mẫu. Do đó sẽ không có sự khác biệt giữa URL và biểu mẫu Method = "GET". Hoặc là một trong những kết quả trong cùng một URL được nạp.

0

Tôi cũng nghe nói rằng < phương thức biểu mẫu = "get" > hoàn toàn tương đương với việc đặt thông số trong URL?

Đó là sự thật, đây là tương ứng RFC section

Có chiều dài tối đa đến một yêu cầu?

spec nói "Giao thức HTTP không đặt bất kỳ giới hạn ưu tiên nào về độ dài của URI".

Tuy nhiên Internet explorer 6 có giới hạn 2.083 ký tự. Các trình duyệt khác cho phép nhiều ký tự hơn nhưng nếu bạn đi theo lộ trình đó, về cơ bản bạn sẽ phải thiết kế cho ie6

+0

Các đặc điểm kỹ thuật HTTP không định nghĩa

yếu tố; bạn cần phải xem xét thông số HTML thay thế. –

1

phương thức biểu mẫu = get S put đặt tất cả đầu vào của biểu mẫu vào URL.

Đúng là các trình duyệt có độ dài tối đa cho URL. Nó thay đổi từ trình duyệt sang trình duyệt và chắc chắn từ phiên bản Trình duyệt thành phiên bản trình duyệt.

Nếu có thể, tôi khuyên bạn nên sử dụng POST cho biểu mẫu của bạn.

HTH

1

GET và url? Name = giá trị & ... là những điều tương tự, như trình duyệt đơn thuần là chuyển đổi một hình thức GET đến một URL trước khi gửi yêu cầu.

Độ dài tối đa của URL được xác định ở cấp trình duyệt và máy chủ như vậy, đối với một trình duyệt/máy chủ cụ thể, đó là phần nhỏ hơn của cả hai trình duyệt/máy chủ.

This post có một danh sách tốt có độ dài tối đa hiện tại cho URL

0

Đây không phải là một câu trả lời cho câu hỏi của bạn về lấy và bưu điện, nhưng trong một tình huống như bạn đang mô tả nó là khá thường xuyên dễ dàng hơn để lưu trữ các phức tạp hơn dữ liệu trên máy chủ và liên kết nó với id phiên hoặc tài khoản người dùng thay vì đặt nó vào URL mỗi lần. Sau đó, bạn có thể chỉ sử dụng số nhận dạng cho phiên đó trong cookie hoặc dưới dạng tham số url để truy xuất hình ảnh.

Điều đó cũng có thể giúp bạn lưu vào bộ nhớ cache các hình ảnh được yêu cầu để bạn không phải trải qua quá trình tạo lại chúng mỗi khi người dùng muốn xem lại biểu đồ cụ thể.

1

Không, máy chủ không thể thấy sự khác biệt giữa việc đưa thông số vào URL và sử dụng MẪU với phương thức GET. Do đó, nếu một URL nhất định có tham số quá dài, việc sử dụng MẪU với phương thức GET sẽ không hữu ích.

POST hoặc GET nên được chọn chủ yếu cho ngữ nghĩa của chúng. GET là cho hành động "an toàn". Đó là, người dùng không nên chịu trách nhiệm về một hoạt động được thực hiện bởi một yêu cầu GET. Phương thức POST được sử dụng cho các hoạt động mà người dùng phải chịu trách nhiệm.

Rất khó chịu, ví dụ: khi tính năng tìm kiếm sử dụng POST. Người dùng không mong đợi một truy vấn đơn giản để thay đổi bất kỳ trạng thái hệ thống quan trọng nào — mà họ mong đợi tìm kiếm là một hoạt động "an toàn".

Mặt khác, nhiều lỗ hổng tồn tại do các thao tác không an toàn có thể truy cập thông qua các yêu cầu GET, cũng như POST. Điều này góp phần vào lỗ hổng bảo mật như XSRF, nơi kẻ tấn công chỉ cần nhận URL "src" độc hại vào thẻ IMG trên trang web hợp pháp.

Đối với trường hợp sử dụng của bạn, Ajax thực sự có thể là một giải pháp thích hợp. Bạn có thể thực hiện một yêu cầu GET cho mỗi điểm được chọn, lưu trữ chúng trong một phiên làm việc tại máy chủ. Khi người dùng hoàn tất việc nhập điểm, yêu cầu GET cuối cùng sẽ truy xuất sản phẩm đã hoàn thành.

3

HTTP specification không đòi hỏi phải đặt thông số của yêu cầu GET vào URI. Sẽ là hợp pháp khi gửi một thông điệp trong một yêu cầu GET như các biểu mẫu sử dụng POST.

Tuy nhiên, các trình duyệt triển khai biểu mẫu GET theo cách này vì một lý do rất tốt: Caching. Yêu cầu GET được dự kiến ​​sẽ được xử lý trên máy chủ mà không có tác dụng phụ. Vì vậy, phản hồi cho yêu cầu GET có thể được lưu vào bộ nhớ cache. Tùy chọn cải thiện hiệu ứng này sẽ bị mất ngay lập tức nếu bạn bắt đầu sử dụng các thông báo trên các yêu cầu GET.

Nếu bạn dự định thiết kế API biểu đồ, bạn có thể muốn xem Google. Họ đã cung cấp một cái rất tốt cho công chúng. Ngay cả khi nó chỉ cho việc học cách đóng gói càng nhiều thông tin vào các tham số URI càng tốt, nó đáng xem.

alt text   alt text   alt text   alt text

+0

+1, tôi thích đối số bộ nhớ đệm. –