国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

【譯】發(fā)送表單數據

Eidesen / 2312人閱讀

摘要:若該特性未指定,則數據會發(fā)送到包含該表單的頁面所在的。其中使用了來處理表單數據。特殊案例發(fā)送文件文件是表單中一個特殊的例子,其他數據都是文本數據,而文件則一般是或者被認為是二進制數據。

系列文章說明

原文

多數時候,HTML表單的目的只是為了把數據發(fā)給服務器,之后服務器再處理這些數據并發(fā)送響應給用戶。雖然看起來挺簡單的,但我們還是得注意一些事情以確保傳送的數據不會破壞服務器、或者給你的用戶制造麻煩。

數據會到哪里去 關于客戶端/服務器架構

整個web都是基于一種基本的客戶端/服務器架構,該架構可以歸納如下:

一個客戶端(通常是Web瀏覽器)使用HTTP協議發(fā)送一個請求給服務器(通常是web服務器程序,譬如Apache, Nginx, IIS, Tomcat等等),而服務器則以相同的協議響應這個請求。

在客戶端,HTML表單只是提供一種比較方便且用戶友好的方式,用來配置發(fā)送給服務器的HTTP請求。這樣用戶就可以自己提供能被HTTP請求傳送的信息。

客戶端:定義如何發(fā)送數據

元素能夠定義其數據如何被發(fā)送,它所有的特性都是為了在用戶點擊發(fā)送按鈕時,讓你配置要發(fā)送的請求。其中最重要的兩個特性是action和method。

action特性

該特性定義了數據會被發(fā)往何處,它的值必須是個合法的URL。若該特性未指定,則數據會發(fā)送到包含該表單的頁面所在的URL。

示例
在下面的例子中,數據會發(fā)送至http://foo.com:


這里,數據會被發(fā)送到表單頁所在的服務器,但到達的卻是服務器上不同的URL:


如下,當不指定任何特性時,表單數據會給發(fā)送到包含該表單的的頁面:


許多老舊的頁面會使用下面的符號來表明,數據得被發(fā)送到包含該表單的的頁面;這在當時是必須的,因為直到HTML5之前,action特性都是必填的。但現在就不再需要了。


注意:可以指定一個使用HTTPS(安全的HTTP)協議的URL,此時數據會隨請求的其他部分一起加密,即使表單本身位于一個通過HTTP訪問的不安全頁面。此外,若表單位于一個安全的頁面,而你卻給action特性指定了一個不安全的HTTP URL,則所有的瀏覽器會在每次用戶要發(fā)送數據時給他們一個安全警告,因為此時這些數據將不被加密。

method特性

該特性定義了數據如何被發(fā)送。HTTP協議提供了幾種方式來執(zhí)行一個請求;HTML表單數據可以通過其中至少方式來發(fā)送:GET和POST。

要理解這兩種方式的不同,我們得回過頭來來看下HTTP是如何工作的。當你想取得Web上的某個資源時,瀏覽器會發(fā)送一個請求給指定的URL。一個HTTP請求含有兩個部分:包含和瀏覽器功能有關的一系列全局字段的請求頭,以及包含要給服務器處理的信息的請求體。

GET方法

瀏覽器使用GET方法來請求服務器發(fā)回指定的資源:“嘿服務器,我想獲得這個資源”。這種情況下,瀏覽器只會發(fā)送一個空的請求體,而正因如此,若瀏覽器使用該方式,那么發(fā)給服務器的數據會給追加到URL后面。

示例
考慮如下表單:


  
  
  

使用GET方法時,HTTP請求看起來就這樣:

GET /?say=Hi&to=Mom HTTP/1.1
Host: foo.com
POST方法

POST方法則稍有不同,瀏覽器發(fā)送這個方法給服務器,用以請求一個和HTTP請求體里數據有關的響應:“嘿服務器,看看這些數據然后給我發(fā)回一個適當的結果”。若表單使用該方法發(fā)送,則數據會給追加到HTTP請求體里。

示例
考慮如下表單(和上面那個一樣):

使用POST方法時,HTTP請求看起來就這樣:

POST / HTTP/1.1
Host: foo.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 13

say=Hi&to=Mom

Content-length頭部字段指示了請求體的大小,而Content-Type字段則標識了發(fā)往服務器的資源類型。我們將在稍后討論下這些請求頭。

當然,HTTP請求是不會展示給用戶看的(若你想看到它們,還得使用諸如火狐的Web Console或者chrome Developer Tools等工具),唯一展示給用戶的,只有訪問的URL。所以使用GET請求時,用戶將會在他們的地址欄看到數據,而使用POST請求則看不到。這點至關重要,原因如下:

若你要發(fā)送密碼(或者任何敏感數據),那千萬別用GET方法,否則該數據會不安全地展示在地址欄上。

若你想要發(fā)送大量數據,最好用POST方法,因為一些瀏覽器會限制URL的大小。此外,許多服務器也會限制接收的URL長度。

服務器端:處理數據

不論你選擇哪種HTTP方法,服務器只會接收到一個字符串并將其解析,再以鍵/值對列表的形式獲取數據。而如何訪問這個列表,取決于你基于何種開發(fā)平臺、以及用了何種框架。你使用的技術也會決定如何處理重復的鍵名,通常某個鍵名最后接收到的值是優(yōu)先被選取的。

示例:原生PHP

PHP提供了幾個全局對象來處理數據。假設你使用POST方法,下面的示例會直接提取你的數據并展示給用戶。當然,要如何處理數據取決于你,你可以展示它、將其存進數據庫、用郵件發(fā)送它、或者其他任何方式。


這個示例會用我們發(fā)送的數據生成一個頁面??紤]我們前面用的表單示例數據,輸出結果會是:

Hi Mom
示例:原生Python

下面的示例使用Python來做相同的事---將給定的數據展示到web頁面上。其中使用了CGI Python package 來處理表單數據。

#!/usr/bin/env python
import html
import cgi
import cgitb; cgitb.enable()     # 用于處理錯誤

print("Content-Type: text/html") # 請求頭字段,標識后面的內容是HTML
print()                          # 空行,表示請求頭的結束

form = cgi.FieldStorage()
say  = html.escape(form["say"].value);
to   = html.escape(form["to"].value);

print(say, " ", to)

結果和之前用PHP處理是一樣的:

Hi Mom
其它語言和框架

還有許多其他的服務端技術可以用來處理表單,比如Perl, Java, .Net, Ruby等等,選擇你最喜歡的一種就好。我們很少直接使用這些技術,因為這么做得需要很多技巧來填坑;通常我們會在眾多好用的框架中選擇一種,這樣會讓表單的處理更容易些,比如:

Symfony for PHP

Django for Python

Ruby On Rails for Ruby

Grails for Java

值得注意的是,就算用了這些框架,處理表單是不一定就會變得輕松。但至少這樣用起來會更好些,還能節(jié)省你不少時間。

特殊案例:發(fā)送文件

文件是HTML表單中一個特殊的例子,其他數據都是文本數據,而文件則一般是、或者被認為是二進制數據。由于HTTP是個文本協議,所以對處理二進制數據得有特別的要求。

enctype特性

該特性能讓你指定HTTP請求頭中的Content-Type字段值,這個字段的重要性在于,它能告訴服務器要發(fā)送的數據類型。其默認值是application/x-www-form-urlencoded,對應的解釋是:“這份表單數據已被編碼為URL格式”。

而當你想發(fā)送文件時,得先做兩件事:

將method特性設置為POST,因為使用表單時,文件內容是不能被放到URL參數里的

將enctype特性的值設為multipart/form-data,這樣數據就會被分割為多個部分,每個文件都會追加上和他們一起發(fā)送的表單有關的文本。

示例:

注意:某些瀏覽器支持元素的multiple特性,以便讓一個input元素能發(fā)送多個文件。至于服務器會如何處理這些文件,就得取決于它用來什么技術了。如前所述,使用框架能讓你的活的輕松些~

警告:為防止濫用,許多服務器會對文件和HTTP請求設置大小限制。所以,最好在發(fā)送文件之前和服務器管理員核實一下這個限制。

安全相關

每次要發(fā)數據給服務器前,你都得考慮下安全問題。HTML表單是針對服務器的首要攻擊載體之一,但該危害的來源并非HTML表單本身,而在于服務器如何處理數據。

常見的安全問題

著名的安全問題有很多,如何劃分取決于你在做什么:

XSS和CSRF

跨站腳本攻擊(XSS)和跨站請求偽造(CSRF)是最常見的攻擊類型,它們會在你展示由用戶發(fā)給用戶的數據時發(fā)生。

XSS讓攻擊者能再其他用戶訪問的Web頁面上注入客戶端腳本。攻擊者會利用跨站腳本的脆弱性來繞過訪問控制策略,譬如同源策略。這種攻擊可以取得從小麻煩到嚴重安全危機不等的危害效果。

CSRF很像XSS,因為它們都以相同的方式開始---注入客戶端腳本到Web頁面,但它們的攻擊目標卻不同。CSRF攻擊者會試著升級權限以成為一個高權限的用戶(比如網站管理員),然后執(zhí)行本不能夠執(zhí)行的動作(如把數據發(fā)送給不受信任的用戶)。

XSS攻擊利用了用戶對網站的信任,而CSRF攻擊則利用了網站對其用戶的信任。

要防止此類攻擊,就得時常校驗用戶發(fā)送給服務器的數據;同時(如果需要展示)也盡量別展示用戶提供的HTML內容,而應該處理用戶提供的數據,以避免將其原封不動地顯示出來。目前幾乎所有市面上的的框架,至少都會實現一個過濾器,用以移除用戶提交數據中

閱讀需要支付1元查看
<