現在，我知道URL和POST參數中的參數之間的區別：如果URL太長，某些瀏覽器可能會行爲不當，因此，在URL中填充數百個參數並不是一個好主意，即使您的應用程序可以迴應GET請求。URL和<form method =「get」>中的參數是否有區別？
爲了便於討論，我們假設下面的Web應用程序：用戶可以輸入一系列（可能是數百個）X，Y座標。服務器將它們繪製在圖表中，作爲圖像返回。
這顯然是idempotent operation的一個例子，所以根據HTTP spec，建議將其作爲GET操作來實現。但是，您無法構建包含所有參數的網址，因爲它會太長。可以通過一個<的form =「get」>來處理那麼多參數？
我也聽說< form method =「get」>完全等同於將參數放在一個URL中嗎？現在，對於某些瀏覽器或整個HTTP協議來說，這是真的嗎？請求的最大長度是多少？
HTTP規範沒有設置限制，但瀏覽器和服務器都這樣做。具體請參見here。
如果方法設置爲表單的GET，瀏覽器將創建一個長URL，因此上述限制適用。
你的瀏覽器實際上做的是從表單輸入構建一個非常長的url。因此，URL和表單Method =「GET」之間沒有區別。任何一個都會導致加載相同的URL。
我也聽說< form method =「get」>完全等同於將參數放入URL中嗎？
這是真的，這裏是相應RFC section
是否有最大長度要求？
spec表示「HTTP協議不會對URI的長度進行任何先驗限制。」
但是，Internet Explorer 6的限制爲2,083個字符。 其他瀏覽器允許更多的字符，但如果你去那條路線，你將基本上必須設計爲ie6
form method = get將把所有表單的輸入到URL中。
確實，瀏覽器具有URL的最大長度。它從瀏覽器到瀏覽器，當然從瀏覽器版本到瀏覽器版本。
如果可以的話，我會建議你使用POST作爲你的表單。
HTH
GET和URL？name = value的& ......都是一樣的東西，因爲瀏覽器只在發送請求之前一個GET形式轉換爲URL。
URL的最大長度是在瀏覽器和服務器級別確定的，因此對於給定的瀏覽器/服務器，它是兩者中較小的一個。
This post有電流最大長度對於網址
一個好名單這不是一個對你關於獲取和職位，但在類似情況下你所描述的是往往更容易儲存更復雜的問題數據並將其與會話ID或用戶帳戶相關聯，而不是每次都將其放入URL中。然後，您可以在Cookie中使用該會話的標識符或作爲url參數來檢索圖像。
這也可以幫助你緩存所需的圖像，所以你不必每次用戶再次看一個特定的圖表時都要重新生成它們。
不，服務器無法看到將參數放入URL中並使用帶有GET方法的FORM之間的區別。因此，如果給定的帶參數的URL太長，那麼使用FORM和GET方法將無濟於事。
POST或GET應該主要選擇它們的語義。 GET用於「安全」操作。也就是說，用戶不應該對由GET請求執行的操作負責。 POST方法用於用戶要負責的操作。
這很令人沮喪，例如，當搜索功能使用POST時。用戶不希望簡單的查詢來改變任何重要的系統狀態—他們期望搜索是「安全」的操作。
另一方面，存在很多漏洞，因爲可以通過GET請求和POST來訪問不安全的操作。這有助於XSRF等攻擊者只需將惡意「src」URL導入合法網站的IMG標記中的漏洞。
對於您的用例，Ajax實際上可能是一個合適的解決方案。您可以爲選定的每個點發出GET請求，將它們存儲在服務器的會話中。當用戶完成輸入點時，最終的GET請求檢索完成的產品。
HTTP specification不明確要求將GET請求的參數放入URI中。使用POST方式在GET請求中發送消息體是合法的。
但是，瀏覽器以這種方式實現GET表單的原因很充分：緩存。預計將在服務器上處理GET請求，而不產生副作用。所以對GET請求的響應可能會被緩存。如果您在GET請求上開始使用消息體，此性能改進選項會立即丟失。
如果您打算設計圖表API，您可能需要查看Google。他們已經向公衆提供了非常好的一個。即使這只是爲了學習如何將盡可能多的信息包裝到URI參數中，它也值得一看。
+1，我喜歡緩存參數。 – 2008-11-05 18:04:34
HTTP規範沒有定義