recursal/MDN huggingface dataset:
503 Service Unavailable
=======================

超文本傳輸協定(英文：HyperText Transfer Protocol (HTTP) ) **`503 Service Unavailable`** 表示目前伺服器暫時不能處理連線的請求。

起因通常是伺服器正在進行維護或是當下流量過載。這種錯誤回傳應該是暫時性的，並且`Retry-After` (en-US) HTTP header 中要盡可能描述到系統大概恢復正常的時間。.

**備註：** 回傳這種錯誤的同時，也要同時顯示一張對使用者友善的網頁，來簡單描述問題。

回傳此錯誤時，務必注意和快取存取相關的標頭（Caching-related headers），因為 503 狀態通常要是暫時性的，而這種回應不應該被暫存至快取。

狀態
--
```

503 Service Unavailable
```

規範
--

| Specification |
| --- |
| HTTP Semantics # status.503 |

瀏覽器相容性
------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

以下資訊是從 MDN 的 GitHub 取得 (https://github.com/mdn/browser-compat-data).

請參閱
---

* `Retry-After` (en-US)
了解更多
----

### 一般知識

* HTTP/1.1: Status Code Definitions
* HTTP Error 503
* 503 Service Unvailaible WordPress
* 如何修復在 WordPress 當中「503 Service Unavailable Error」的問題？
200 OK
======

HTTP **`200 OK`** 成功狀態碼表明請求成功。200 回應預設上是緩存的（cacheable）。

所謂「成功」的定義，取決於 HTTP 的請求方法：

* `GET`：資源已取得，並傳送到訊息內文（message body）。
* `HEAD` (en-US)：整個標已經放在訊息內文了。
* `POST` (en-US): 描述動作結果的資源已經傳送到訊息內文。
* `TRACE` (en-US)：訊息內文包含了請求訊息，伺服器也接受了請求。

`PUT` (en-US) 或 `DELETE` (en-US) 的成功訊息，通常不是 `200 OK`，而是 `204` `No Content`（或著在資源首次上傳時，`201` `Created`）。

狀態
--
```

200 OK
```

規範
--

| Specification |
| --- |
| HTTP Semantics # status.200 |

瀏覽器相容性
------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

參見
--

* HTTP 請求方法
415 Unsupported Media Type
==========================

HTTP **`415 Unsupported Media Type`** 用戶端的錯誤表示被請求資源的多媒體類型不被伺服器支援，因此該請求被拒絕。

該格式問體可能源自於請求中設置的 `Content-Type` 或 `Content-Encoding` (en-US) 或對資料的直接訪問。

狀態
--
```

415 Unsupported Media Type
```

規範
--

| Specification |
| --- |
| HTTP Semantics # status.415 |

參見
--

* `Content-Type`
* `Content-Encoding` (en-US)
* `Accept`
409 Conflict
============

HTTP **`409 Conflict`** 表示請求與伺服器目前狀態衝突

衝突通常發生於 `PUT` (en-US) 請求。如上傳一個已經有舊版本存在於伺服器的檔案而導致版本控制衝突時，會回復一個 409 錯誤。

狀態
--
```

409 Conflict
```

規範
--

| Specification |
| --- |
| HTTP Semantics # status.409 |

參見
--

* `PUT` (en-US)
411 Length Required
===================

超文本傳輸協定 (HTTP) **`411 Length Required`** 用戶端錯誤表示伺服器拒絕接收沒有定義 `Content-Length` (en-US) 頭的請求。

**備註：** by specification, when sending data in a series of chunks, the `Content-Length` header is omitted and at the beginning of each chunk you need to add the length of the current chunk in hexadecimal format. See `Transfer-Encoding` (en-US) for more details.

狀態
--
```

411 Length Required
```

規範
--

| Specification |
| --- |
| HTTP Semantics # status.411 |

參見
--

* `Content-Length` (en-US)
* `Transfer-Encoding` (en-US)
205 Reset Content
=================

HTTP **`205 Reset Content`** 狀態碼用來通知客戶端重置文件視圖，例如：清除表單內容、重置畫布狀態或刷新使用者界面。

狀態
--
```

205 Reset Content
```

規範
--

| Specification |
| --- |
| HTTP Semantics # status.205 |

相容性事項
-----

* 若是此回應在持久連線中錯誤地包含了主體，不同瀏覽器將會有不同的行為。細節參見 204 No Content 。
參見
--

* `204` No Content
502 Bad Gateway
===============

`502 Bad Gateway` 錯誤表明伺服器以閘道器或代理訪問時，收到了來自上游服務器的無效回應。

**備註：** 閘道器可能位於網路上的不同地方。502 錯誤通常也不是開發者可以修復的，他通常需要在要訪問的的伺服器或代理修復之。

狀態
--
```

502 Bad Gateway
```

規範
--

| Specification |
| --- |
| HTTP Semantics # status.502 |

瀏覽器相容性
------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

The information shown below has been pulled from MDN's GitHub (https://github.com/mdn/browser-compat-data).

See also
--------

* WordPress 出現 502 Bad Gateway Error 解決方法
* `504`
* HTTP/1.1: Status Code Definition
* 502 bad gateway fix
* 502 Bad Gateway error on WordPress
* 502 error with Cloudflare
404 Not Found
=============

HTTP **`404 Not Found`** 用戶端錯誤回應碼，表明了伺服器找不到請求的資源。引發 404 頁面的連結，通常被稱作斷連或死連（broken or dead link）、並可以導到失效連結（link rot）頁面。

404 狀態碼並沒有表明資源是暫時不見、還是永遠不見。如果資源是永遠不見，就應該用 `410` (en-US)(Gone) 而不是 404。

狀態
--
```

404 Not Found
```

自訂錯誤頁面
------

很多網站都會自訂 404 錯誤頁面，以便在指引用戶後續動作方面，提供進一步的幫助。Apache 伺服器可以透過 `.htaccess` 檔案設定，程式碼如下：


```bash
ErrorDocument 404 /notfound.html
```


要參考自訂 404 錯誤頁面範例，請看看 MDN 的 404 頁面。

**備註：** 適度地客製是件好事：你可以讓 404 頁面幽默和人性化，但不要讓用戶困惑。

規範
--

| Specification |
| --- |
| HTTP Semantics # status.404 |

瀏覽器相容性
------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

參見
--

* `410` (en-US)
* 維基百科的 HTTP 404
* 404 Error
418 I'm a teapot
================

HTTP **`418 I'm a teapot`** 用戶端錯誤碼表明了伺服器是個（永久性的）茶壺，所以拒絕煮咖啡。一個結合了咖啡與茶壺的壺子暫時沒咖啡的情境，應該回傳 503。這個錯誤是源自於 1998 與 2014 的愚人節玩笑「超文字咖啡壺控制協定」（Hyper Text Coffee Pot Control Protocol）。

狀態
--
```

418 I'm a teapot
```

規範
--

| Specification |
| --- |
| RFC 2324 # section-2.3.2 |

瀏覽器相容性
------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

參見
--

* 維基百科的「超文字咖啡壺控制協定」
201 Created
===========

HTTP **`201 Created`** 成功狀態碼表示請求成功且有一個新的資源已經依據需要而被建立。實際上，在此回應傳送前，新資源就已被建立，且其內容在訊息的主體中傳回，其位置為請求的 URL 或是 `Location` (en-US) 標頭的內容。

此狀態碼通常用於 `POST` (en-US) 請求的回應中。

狀態
--
```

201 Created
```

規範
--

| Specification |
| --- |
| HTTP Semantics # status.201 |

瀏覽器相容性
------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

參見
--

* HTTP 請求方法
101 Switching Protocols
=======================

HTTP **`101 Switching Protocols`** 回應碼表示伺服器正在切換到用戶端在請求標頭`Upgrade` (en-US) 中所要求的通訊協定。

伺服端將在回應中包含 `Upgrade` (en-US) 標頭以表明其所切換的通訊協定。此過程在文章 Protocol upgrade mechanism 中有更加詳細的描述。

狀態
--
```

101 Switching Protocols
```

範例
--

通訊協定切換可能會用於 WebSockets 中。
```

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
```

規範
--

| Specification |
| --- |
| HTTP Semantics # status.101 |

參見
--

* Protocol upgrade mechanism
* WebSockets
* `Upgrade` (en-US)
* `426` (en-US) `Upgrade Required`
500 Internal Server Error
=========================

HTTP **`500 Internal Server Error`** 伺服器錯誤回應表明了伺服器碰上意外情況，令伺服器無法完成請求。不管你的網站是不是採用 WordPress 系統，任何放在伺服器當中的網頁都有可能發生這種錯誤。

本錯誤回應屬於通用的「全方位」回應。一般來說，這代碼代表程式無法給出比 500 更適當的回應。有時候，伺服器管理者會針對 500 這樣的錯誤回應，記錄詳細的相關信息，以避免未來出現同樣的錯誤。

狀態
--
```

500 Internal Server Error
```

規範
--

| Specification |
| --- |
| HTTP Semantics # status.500 |

瀏覽器相容性
------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

參考資料
----

* 如何修復 WordPress 出現 500 Internal Server Error 的解決方法
* 500 Internal Server Error
301 Moved Permanently
=====================

HTTP **`301 Moved Permanently`** 重新導向狀態代碼代表所請求的資源已經被明確移動到 `Location` (en-US) 標頭所指示的 URL。瀏覽器會重新導向到此頁面，而搜尋引擎則會更新該資源的連結。用 SEO 的話來說，就是連結養分（link-juice）把你送到了新的 URL 去。

儘管規範要求當執行重新導向時，請求方法（以及主體）不應該被更動，但並非所有的用戶代理皆遵循它——你依然可以找到具有此類漏洞的軟體。因此，推薦只使用 `301` 回應碼作為 `GET` 或 `HEAD` (en-US) 方法的回應，另外使用 `308 Permanent Redirect` (en-US) 作為 `POST` (en-US) 方法的替代，因為請求方法的更動在此狀態中是被明確禁止的。

狀態
--
```

301 Moved Permanently
```

範例
--

### 用戶端請求
```

GET /index.php HTTP/1.1
Host: www.example.org
```

### 伺服端回應
```

HTTP/1.1 301 Moved Permanently
Location: http://www.example.org/index.asp
```

規範
--

| Specification |
| --- |
| HTTP Semantics # status.301 |

瀏覽器相容性
------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

參見
--

* `308 Permanent Redirect` (en-US)
* `302 Found` (en-US), 臨時重新導向
504 Gateway Timeout
===================

**`504 Gateway Timeout`** 錯誤表明伺服器以閘道器或代理訪問時，並沒有上游伺服器即時收到完成請求所需的回應。

**備註：** 閘道器可能位於網路上的不同地方。502 錯誤通常也不是開發者可以修復的，通常需要在要訪問的的伺服器或代理修復之。

狀態
--
```

504 Gateway Timeout
```

規範
--

| Specification |
| --- |
| HTTP Semantics # status.504 |

瀏覽器相容性
------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

The information shown below has been pulled from MDN's GitHub (https://github.com/mdn/browser-compat-data).

See also
--------

* HTTP/1.1: Status Code Definitions
* `502`
203 Non-Authoritative Information
=================================

HTTP **`203 Non-Authoritative Information`** 狀態碼表明請求成功，但是與原始伺服器的 `200` (`OK`) 回應相比，隨附的酬載已被具轉換功能的 代理伺服器 (en-US) 所修改。

`203` 回應相似於 `Warning` (en-US) 標頭的 `214 Transformation Applied`，但後者的額外的優點在於可以套用到任何狀態碼的回應中。

狀態
--
```

203 Non-Authoritative Information
```

規範
--

| Specification |
| --- |
| HTTP Semantics # status.203 |

參見
--

* `200`
* Proxy server (en-US)
* `Warning` (en-US)
451 Unavailable For Legal Reasons
=================================

HTTP **`451 Unavailable For Legal Reasons`** 用戶端錯誤回應碼表明用戶請求的資源，出於法律原因而無法使用，例如遭受法律訴訟的網頁。

狀態
--
```

451 Unavailable For Legal Reasons
```

示例
--

此示例擷取自 IETF RFC（參見以下章節）、包含了萬世魔星的引用。

**註：**`Link` (en-US) 標頭可能包含 `rel="blocked-by"` 以表明是誰封鎖該資源，而非來自其他強制力量。

需要為該資源無效的負責者，例如請求法律移除內容的人名或組織名，並不會放在 `rel="blocked-by"` link 裡面。
```

HTTP/1.1 451 Unavailable For Legal Reasons
Link: <https://spqr.example.org/legislatione>; rel="blocked-by"
Content-Type: text/html
```


```
<html>
      <head><title>Unavailable For Legal Reasons</title></head>
      <body>
            <h1>Unavailable For Legal Reasons</h1>
            <p>This request may not be serviced in the Roman Province
            of Judea due to the Lex Julia Majestatis, which disallows
            access to resources hosted on servers deemed to be
            operated by the People's Front of Judea.</p>
     </body>
</html>
```

規範
--

| Specification |
| --- |
| An HTTP Status Code to Report Legal Obstacles # n-451-unavailable-for-legal-reasons |

瀏覽器相容性
------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

The information shown below has been pulled from MDN's GitHub (https://github.com/mdn/browser-compat-data).

參見
--

* 維基百科的 HTTP 451
* 維基百科的華氏 451 度（該請求碼的數字詞源）
206 Partial Content
===================

HTTP **`206 Partial Content`** 成功狀態碼表明請求成功，且主體包含在請求標頭`Range` (en-US) 中所指定的資料區間。

若只包含一個區間，則整個回應的 `Content-Type` 將會被設為該文件的類型 ，且會包含一個 `Content-Range` (en-US) 標頭。

若有多個區間，則整個回應的 `Content-Type` 會被設為 `multipart/byteranges` ，且每個分段會對應一個區間，並有 `Content-Range` (en-US) 及 `Content-Type` 描述各個區間。

狀態
--
```

206 Partial Content
```

範例
--

一個包含單一區間的回應：
```

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 2015 06:25:24 GMT
Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

... 26012 bytes of partial image data ...
```


一個包含多個區間的回應：
```

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 2015 06:25:24 GMT
Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
Content-Length: 1741
Content-Type: multipart/byteranges; boundary=String_separator

--String_separator
Content-Type: application/pdf
Content-Range: bytes 234-639/8000

...the first range...
--String_separator
Content-Type: application/pdf
Content-Range: bytes 4590-7999/8000

...the second range
--String_separator--
```

規範
--

| Specification |
| --- |
| HTTP Semantics # status.206 |

瀏覽器相容性
------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

參見
--

* `If-Range` (en-US)
* `Range` (en-US)
* `Content-Range` (en-US)
* `Content-Type`
300 Multiple Choices
====================

HTTP **`300 Multiple Choices`** 重定向回應碼代表該請求具有超過一種可能的回應。用戶代理或使用者應該從中挑選一個。由於不存在標準化的選擇回應方式，此回應碼非常少被使用。

若是伺服端有偏好的選擇，則應該產生 `Location` (en-US) 標頭。

狀態
--
```

300 Multiple Choices
```

規範
--

| Specification |
| --- |
| HTTP Semantics # status.300 |

參見
--

* `301` `Moved Permanently`
* `302` (en-US) `Found`, the temporary redirect
* `308` (en-US) `Permanent Redirect`
202 Accepted
============

HTTP **`202 Accepted`** 成功狀態碼表示此請求已經被接受但尚未處理。此狀態為非承諾性，代表 HTTP 無法在之後傳送一個非同步的回應告知請求的處理結果。最初目的為外部程序或其他伺服器處理請求的情況，或用於批次處理中。

狀態
--
```

202 Accepted
```

規範
--

| Specification |
| --- |
| HTTP Semantics # status.202 |

參見
--

* `Accept`
403 Forbidden
=============

HTTP **`403 Forbidden`** 客戶端錯誤狀態碼表示伺服器理解該請求但拒絕核准。

該狀態碼與 HTTP `401` (en-US) 類似，但重新身分驗證不能提供幫助。 存取被永久性禁止，且與應用程式邏輯有關，如資源的訪問權限不足。

狀態
--
```

403 Forbidden
```

回應範例
----
```

HTTP/1.1 403 Forbidden
Date: Wed, 21 Oct 2015 07:28:00 GMT
```

規範
--

| Specification |
| --- |
| HTTP Semantics # status.403 |

瀏覽器相容性
------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

參見
--

* `401` (en-US)
100 Continue
============

HTTP **`100 Continue`** 訊息狀態回應碼表示，目前為止的一切完好，用戶端應該繼續完成請求，或當請求已經完成的狀態下應忽略此訊息。

若要使伺服器確認請求標頭，用戶端必須在最初請求的標頭中，傳送`Expect` (en-US)`: 100-continue` ，並且在傳送主體前，接收 `100 Continue` 狀態碼。

狀態
--
```

100 Continue
```

規範
--

| Specification |
| --- |
| HTTP Semantics # status.100 |

瀏覽器相容性
------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

參見
--

* `Expect` (en-US)
* `417` (en-US)
行動無障礙檢核清單
=========

本文提供行動應用程式開發者一個簡潔的無障礙必備要件檢核清單，本文將隨著更多模型產生而不斷地演進。

顏色
--

* 顏色對比**必須**符合WCAG 2.0 AA 等級要求:
    + 一般文字對比值為 4.5:1(小於 18 點字或 14 點粗體)
    + 大文字對比值為 3:1(大於 18 點字或 14 點粗體)
* 透過顏色傳遞資訊 **必須** 能藉由其他方式獲得資訊 (底線文字表示連結等)

**備註：** Jon Snook 已撰寫實用的 Colour Contrast Checker 能用於檢查背景與前景顏色的對比。同樣地，Tanaguru Contrast-Finder 也提供類似功能，而且建議相似且更好的對比顏色提供你考量使用。

可視性
---

* 內容隱藏技術如完全不透明、Z 型態索引順序與螢幕外的配置**必須不能**單獨用於處理可視性。
* 目前可視螢幕之外的所有事物**必須**真正地不可見(特別適用於具有多個卡片的單一頁面應用程式)：
    + **使用** `hidden` 屬性或 `visibility` 或 `display` 樣式屬性。
    + 除非絕對無法避免，否則**不應**使用`aria-hidden` 屬性。
焦點
--

* 所有可觸發的元素**必須**可獲得焦點：
    + 標準的控制措施如連結、按鈕與表單輸入框預設為可獲得焦點。
    + 非標準的控制措施**必須**賦予它們合適的 ARIA Role，如按鈕、連結或核取框。
* 焦點應該以邏輯的順序與一致的方式處理。
文字相等意義
------

* 在應用程式之中，為每一個非嚴格呈現的非文字元素提供文字相等意義。
    + 在適當情況下使用*alt 與 title*(使用指引請參見 Steve Faulkner 關於Using the HTML title attribute的文章)。
    + 如果上述屬性不適用，則使用合適的ARIA 屬性如`aria-label`、`aria-labelledby`或 `aria-describedby。`
* 文字圖片 **必須**避免使用。
* 所有表單控制措施**必須**有標籤(`<label>` (en-US) 元素) ，以利於螢幕報讀器使用者使用。
處理狀態
----

* 標準控制措施如選項按鈕與核取框可被作業系統處理。然而，其他客製的控制措施狀態改變必須透過ARIA 狀態如 `aria-checked`、`aria-disabled`、`ria-selected`、`aria-expanded`與`aria-pressed`來提供。
一般準則
----

* 應用程式的名稱**必須**提供。
* 標題**必須**不能破壞層級結構。

```html
<h1>Top level heading</h1>
<h2>Secondary heading</h2>
<h2>Another secondary heading</h2>
<h3>Low level heading</h3>
```

* ARIA 地標角色**應該**用於描述應用程式或文件結構，例如`banner`、`complementary`、`contentinfo`、 `main`、 `navigation`、`search`。
* 觸控事件處理器**必須**只有在`touchend`事件上觸發。
* 觸控目標**必須**提供使用者足夠大的互動操作(有用的觸控目標大小指引請參見BBC Mobile Accessibility Guidelines)。

**備註：** Tanaguru 自動無障礙測試服務提供有用的方法去發現一些發生於網頁或安裝的網頁應用程式(如 Firefox OS)無障礙錯誤。你可在tanaguru.org找到更多關於 Tanaguru 技術開發，以及貢獻該專案的資訊。

**備註：** 本文件原始版本由Yura Zenevich撰寫。
Using ARIA
==========

Roles（角色）
---------

### Widget roles（局部組件）

* Button （按鈕）
* Checkbox （複選核取方塊）
* Dialog （對話）
* Gridcell （網格欄）
* Link （超連結）
* Log （紀錄）
* Marquee
* Menuitem
* Menuitemcheckbox
* Menuitemradio
* Option
* Progressbar （進度條）
* Radio （單選選項鈕）
* Scrollbar
* Slider （滑軌控制鈕）
* Spinbutton
* status （狀態）
* Tab （頁籤）
* Tabpanel （頁籤面板）
* textbox （頁籤容器）
* Timer （計時器）
* Tooltip （提示）
* Treeitem
* switch （開關） (en-US)
### Composite roles

下面的技術，描述了每個複合角色，以及他們的必要和可選的子角色。

* Combobox （組合框）
* Grid （網格）(包含 row （橫列）, gridcell （網格欄）, rowheader （橫列表頭）, columnheader （欄表頭） roles)
* Listbox （列表框） (包含 option role)
* Menu （選單）
* Menubar （選單條）
* Radiogroup （單選選項群組） (see radio role)
* Tablist （頁籤列表） (包含 tab 和 tabpanel roles)
* Tree
* Treegrid
### Document structure roles

* Article
* Definition
* Directory
* Document
* Group
* Heading
* Img
* List
* Listitem
* Math
* Note
* Presentation
* Region
* Separator
* Toolbar
### Landmark roles

* Application
* Banner
* Complementary
* Contentinfo
* Form
* Main
* Navigation
* Search
States and properties
---------------------

### Widget attributes

* aria-autocomplete
* aria-checked
* aria-current
* aria-disabled
* aria-expanded
* aria-haspopup
* aria-hidden
* aria-invalid
* aria-label
* aria-level
* aria-multiline
* aria-multiselectable
* aria-orientation
* aria-pressed
* aria-readonly
* aria-required
* aria-selected
* aria-sort
* aria-valuemax
* aria-valuemin
* aria-valuenow
* aria-valuetext
### Live region attributes

* aria-live
* aria-relevant
* aria-atomic
* aria-busy
### Drag & drop attributes

* aria-dropeffect
* aria-dragged
### Relationship attributes

* aria-activedescendant
* aria-controls
* aria-describedby
* aria-flowto
* aria-labelledby
* aria-owns
* aria-posinset
* aria-setsize
弱簽章演算法
======

### 簽章演算法的重要性

在簽署憑證時，雜湊演算法的完整性是非常重要的一環。雜湊演算法的漏洞可能導致攻擊者獲取假造的憑證。隨著科技發展出現更多可行的攻擊新手法，並不建議繼續使用舊的演算法，且這些演算法最終該被移除。

### SHA-1

以 SHA-1 為基礎的簽章非常普遍：因為到目前為止大部分憑證皆使用 SHA-1。然而考慮到 SHA-1 已經太過老舊，不建議繼續使用下去。當未來要替換憑證時，請先確認使用的是強簽章演算法。更多資訊請查閱 Mozilla Security Blog post 上的內容。

### MD5

以 MD5 為基礎的簽章已在 2012 初被移除。
不安全的密碼
======

提供 HTTP 的登入表單非常危險，因為目前有很多已知的用戶密碼擷取手法。竊聽者可以透過側錄該網路或修改傳輸頁面進行大量的惡意攻擊，並直接竊取用戶憑證或密碼。本頁將詳細說明 Firefox 用以警示用戶與開發者有關不安全的密碼及密碼竊取風險的安全機制。

HTTPS (en-US) 通訊協定，旨在保護用戶的資料於傳輸時不會遭到竊聽與竄改，並保護其機密性與原始完整性。負責處理用戶資料的網站應使用 HTTPS 保護其用戶不受惡意駭客攻擊。如果沒有使用 HTTPS，竊取諸如登入憑證之類的用戶資訊是小事一樁。著名的 Firesheep 附加套件曾示範過此種攻擊方式。

要處理這個問題，請安裝並設定網站伺服器的 SSL/TLS 憑證。目前有許多免費與付費的憑證供應商。如果是使用雲端，雲端服務商可能提供了啟動 HTTPS 的方法。

重複使用相同密碼
--------

網站有時會需要用戶名稱與密碼，但並不實際儲存敏感資料。例如，新聞網站可能會儲存用戶想要再次閱覽的文章，但不會儲存其它用戶資料。上述範例的網頁開發者可能較無動機保護他們的網站與用戶憑證。

不幸的是，重複使用相同密碼是非常危險的。用戶在多個網站皆使用相同密碼(如新聞網站、社群網站、電子信箱等)。因此，即使非法存取貴網站的用戶名稱與密碼並不對你構成嚴重問題，對於在不同網站(如網路銀行)使用相同名稱與密碼的用戶而言，卻會造成嚴重威脅。攻擊者愈來愈聰明，他們會從一個網站竊取用戶名稱與密碼的配對，並在更有利可圖的網站上重複嘗試。

參見
--

* No More Passwords over HTTP, Please! — 提供詳細資訊和常見問題的部落格文章
同源政策 (Same-origin policy)
=========================

同源政策限制了程式碼和不同網域資源間的互動。

同源定義
----

所謂同源是指兩份網頁具備相同協定、埠號 (如果有指定) 以及主機位置，下表提供了一些例子展示那些來源和 `http://store.company.com/dir/page.html` 屬於同源:

| URL | Outcome | Reason |
| --- | --- | --- |
| `http://store.company.com/dir2/other.html` | 同源 |  |
| `http://store.company.com/dir/inner/another.html` | 同源 |  |
| `https://store.company.com/secure.html` | 不同源 | 協定不同 |
| `http://store.company.com:81/dir/etc.html` | 不同源 | 埠號不同 |
| `http://news.company.com/dir/other.html` | 不同源 | 主機位置不同 |

另外請參考 file 來源定義: URL。

Cookie 的來源定義和上述不一樣。

變更來源
----

網頁能夠有限地變更來源，我們可以將 `document.domain` (en-US) 存為目前網域後半部，然後較短的網域就會作為之後來源檢查，譬如我們在 `http://store.company.com/dir/other.html` 的文件裡執行以下程式碼:
```

document.domain = "company.com";
```


執行完後，網頁能以 `http://company.com/dir/page.html` 通過同源檢查。然而基於同源檢查，company.com 無法將 document.domain 存為 othercompany.com。

任何變更 document.domain 行為，包括 document.domain = document.domain 都會導致埠號重置為 null，因此無法只藉由執行 document.domain = "company.com" 讓 company.com:8080 和 company.com 互動，必須兩邊都重新設定好讓埠號都一致重置為 null。

**備註：** 為了讓子網域可以安全的存取其母網域，我們需要一起改變子、母網域的 document.domain 為相同值，即使只是將母網域設回原始值也是必要，否則將會導致許可權錯誤 (Permission Error)。

跨來源網路存取
-------

同源政策控制了兩個不同網域來源互動，例如當使用`XMLHttpRequest`。這些互動可分為以下三類:

* 跨來源寫(Cross-origin writes)通常被允許，例如有連結、重新導向以及表單送出。少數某些 HTTP 請求需要先導請求。
* 跨來源嵌入(Cross-origin embedding)通常被允許，例子請參照下方。
* 跨來源讀取(Cross-origin read) 通常不被允許，不過通常可以藉由嵌入來繞道讀取，例如嵌入影像寬高讀取、嵌入程式碼或嵌入資源。

下面是一些能跨來源嵌入的資源:

* `<script src="…"></script>` 內的 JavaScript，但語法錯誤訊息只限於同源程式碼腳本。
* CSS 的 `<link rel="stylesheet" href="...">`，由於 CSS 寬鬆語法規則，跨來源 CSS 要求正確的 Content-Type 標頭。限制在瀏覽器間各有差異: IE, Firefox, Chrome, Safari (請至 CVE-2010-0051)以及Opera.
* `<img>` (en-US)的影像；支援格式有 PNG, JPEG, GIF, BMP, SVG 等等
* `<video>` (en-US)和`<audio>` (en-US)媒體檔案
* `<object>` (en-US), `<embed>` (en-US)和`<applet>`的外掛
* `@font-face` 的字型；有些瀏覽器允許跨來源字型，有些則不。
* `<frame>` (en-US)以及`<iframe>` (en-US)中的內容；如果一個網站想要避免跨來源載入互動，可以藉由`X-Frame-Options`標頭避免。
### 如何允許跨來源存取

使用CORS允許跨來源存取

### 如何阻擋跨來源存取

* 藉由檢查請求中包含的無法猜測的特殊記號(token)可以避免跨來源寫入，還有跨來源讀取知道此記號的網頁，這個記號即為跨站偽造(Cross-Site Request Forgery, CSRF)記號。
* 確保資源無法被嵌入來防止跨來源讀取。
* 為了防止跨來源嵌入，請確保資源不被解讀為上述可嵌入格式之一；瀏覽器通常不會理會 Content-Type，比如說有一個指向 HTML 文件的<script>標籤，瀏覽器還是會嘗試解析該 HTML 文件為 Javascript；當你的資源不是網站進入點，可以使用 CSRF 記號。
跨來源程式腳本存取
---------

Javascript API 例如`iframe.contentWindow` (en-US), `window.parent` (en-US), `window.open` (en-US)以及`window.opener`，允許文件之間直接互相參照，當兩份文件的來源不同，參照存取Window和Location物件將受到限制；一些瀏覽器比規範准許存取更多屬性。文件間的溝通也可以改用`window.postMessage` (en-US)來進行。

延伸閱讀
----

* Same-origin policy for file: URIs
* Same-Origin Policy at W3C
混合內容
====

當使用者以 HTTPS (en-US) 瀏覽網站時，他們與伺服器之間的連線就會以 TLS (en-US) 加密，以防受到竊聽或中間人攻擊。一個含有 HTTP 明文內容的 HTTPS 頁面稱為**混合內容（mixed content）**。這種頁面只有部份加密，沒有加密的內容，易於遭到竊聽和中間人攻擊。這會令網頁不安全。

混合內容的類型
-------

混合內容的類型有兩種：**被動/顯示型混合內容（mixed passive/display content）**與**主動型混合內容（mixed active content）**。兩者不同處在於內容遭中間人攻擊竄改後，其最壞情況下的威脅程度。如果是被動型混合內容，威脅程度較低（可能有錯誤內容、或者用戶的 cookie 遭到竊取）。如果是主動型混合內容，威脅就可能會變成網絡釣魚、敏感資料洩露、被重定向到惡意網站……等等。

### 被動/顯示型混合內容

被動/顯示型混合內容內容是指包在 HTTPS 頁面，但無法改變其他部分的 HTTP 內容。例如，攻擊者能把放在 HTTP 的圖像，換成對用戶而言不適當的圖片或訊息。攻擊者也能監看圖片提供給哪些用戶，來推斷用戶活動的相關資訊：圖片通常只能在網站內的特定頁面提供。如果攻擊者觀察了某些圖片的 HTTP 請求，他們還能確認用戶在訪問哪個網頁。

#### 被動型混合內容清單

以下列出會被視為被動型混合內容的 HTTP 請求：

* `<img>` (en-US)（`src` 屬性）
* `<audio>` (en-US)（`src` 屬性）
* `<video>` (en-US)（`src` 屬性）
* `<object>` (en-US) subresource（如果 `<object>` 發起 HTTP 請求）
### 主動型混合內容

**主動型混合內容**是指有權訪問文件 HTTPS 頁面、物件模型的內容。這種混合內容可以改變 HTTPS 頁面行為、並暗自竊取用戶的敏感資訊。因此，主動型混合內容除了內容除了上文所述的風險外，還容易受到其他攻擊媒介的威脅。

針對主動型混合內容，中間人攻擊者可以攔截 HTTP 內容的請求、並竄改回應以植入惡意 JavaScript 程式碼。惡意的主動型混合內容能竊取用戶的憑證、用戶的敏感資料、甚至透過如瀏覽器或套件的漏洞，嘗試安裝惡意軟體。

混合內容涉及的風險，取決於用戶訪問的網站類型、還有該網站資訊的敏感程度。網頁可能有公諸於世的公開資料、也可能有僅限授權者閱覽的私人資料。即使網頁是公開的，也沒有用戶的敏感資料，混合內容依舊給攻擊者把用戶重定向到其他 HTTP 頁面、並從這些網站竊取 HTTP cookie 的機會。

#### 主動型混合內容示例

以下列出會被視為主動型混合內容的 HTTP 請求：

* `<script>`（`src` 屬性）
* `<link>` (en-US)（`href` 屬性）（包含 CSS 樣式表）
* `<iframe>` (en-US)（`src` 屬性）
* `XMLHttpRequest` 請求
* `fetch()` (en-US) 請求
* 所有用到 `url()` (en-US) 的 CSS 值（`@font-face`、`cursor` (en-US)、`background-image` (en-US)……等等）。
* `<object>` (en-US)（`data` 屬性）

其他資源如 web fonts 與 workers 也可能被認定為主動型混合內容，因為在 Chromium 就是這樣。

網頁主控台的警告
--------

Firefox 網頁主控台會在網站含有混合內容時，於「網路」標籤顯示警告。以 HTTP 傳輸的混合內容資源會被標為紅色，後面會附上導往這一頁的「混合內容」標註。

![Screen shot of the web console displaying a mixed content warning.](/zh-TW/docs/Web/Security/Mixed_content/mixed_content_-_net_pane.png)

找到網頁主控台的警告後，可以在你的網站使用 Content Security Policy (CSP) (en-US) 或網站爬蟲找到問題，，例如 HTTPS Checker 或是 Mixed Content Scan。

從 Firefox 23 以後，預設會封鎖混合內容（要封鎖混合的顯示內容也可以設定）。為了令 web 開發者便於尋找混合內容的錯誤，所有遭到封鎖的混合內容會被紀錄到網頁主控台的安全標籤，如下所示：

![A screenshot of blocked mixed content errors in the Security Pane of the Web Console](/zh-TW/docs/Web/Security/Mixed_content/mixed_content_webconsole.png)

要修正這個錯誤，就要移除所有的 HTTP 請求、並以 HTTPS 取代之。部份例子包含 JavaScript 檔案、CSS 樣式表、影像檔、影片檔或是其他多媒體文件。

**備註：** Firefox 55 以後，在本機端會允許混合內容的載入（請參見 Firefox bug 903966）。

參見
--

* Mixed Content - W3C Editor's Draft
* 如何修正含有混和內容的網站
如何修正含有混合內容的網站
=============

自 Firefox 23 (en-US) 起，Firefox 會預設阻擋主動型混合內容。這項動作是跟在 IE 9 和 Chrome 後實行的。

本頁面會告訴你，身為一個網頁開發者需要知道甚麼。

你的網站可能出問題了
----------

如果你的網站由 HTTPS 傳輸，那麼本頁所有由 HTTP 接收的主動型混合內容就會被封鎖。你的網站可能就會讓使用者遇到一些問題（像是 iframes 或擴充套件無法載入…之類的）。至於 被動型混合內容 預設是會顯示出來的，可是使用者也可以設定將這類內容擋下來。

值得注意的是，由於阻擋混合內容已經在 Chrome 和 Internet Explorer 中實行了，所以如果你的網站已經在這些瀏覽器中出問題，那麼在 Firefox 也很有可能會發生相同情況。

在任何情況下，要知道網站是否出問題的最好方法，就是下載 最新的 Firefox Developer Edition，然後到網站中的不同頁面打開網頁主控台（要啟用「安全」訊息）、並檢查是否有任何混合內容的回報。也可以用 SSL-check or Missing Padlock 這網路爬蟲、或是桌面桌面， HTTPSChecker 來檢查並抓出不安全的內容、另外還有文字介面的工具 mcdetect。如果檢查不到任何有關於混和式內容的東西，就代表你的網站狀態良好：繼續建置你出色的網站吧！

如何修復你的網站
--------

避免混合內容阻塞最好的方法，就是使用 HTTPS 而不是 HTTP 來傳輸所有的內容。

\*\*對於你自己的域名，\*\*使用 HTTPS 來傳輸所有內容並修正你的連結。一般而言 HTTPS 版本的內容都已經存在了，只需要在連結後面加上「s」：就是將 http:// 改成 https:// 。

但有時候，媒體的路徑可能不正確。按照作業系統的不同，你可以使用線上或離線的工具如 linkchecker 來解決問題。

\*\*對於其他域名，\*\*盡可能使用該網站的 HTTPS 版本。如果 HTTPS 不能用，試著跟域名擁有者聯絡並詢問他們是否可以使用 HTTPS 傳輸內容。