2013-07-07 13:29

[轉載][CSS] drop-shadows without images

轉載自:CSS drop-shadows without images

Lifted corners

Curled corners

Perspective

Raised box

Single vertical curve

Vertical curves

Single horizontal curve

Horizontal curves

Rotated box

2013-07-05 00:05

[轉載][MySQL] Storage Engines

轉載自:Chapter 14. Pluggable Storage Engine Architecture

第14章:插件式儲存引擎體系結構


目錄
14.1. 前言
14.2. 概述
14.3. 公共MySQL資料庫伺服器層
14.4. 選擇儲存引擎
14.5. 將儲存引擎指定給資料表
14.6. 儲存引擎和事務
14.7. 插入儲存引擎
14.8. 拔出儲存引擎
14.9. 插件式儲存器的安全含義


14.1. 前言


在MySQL 5.1中,MySQL AB引入了新的插件式儲存引擎體系結構,允許將儲存引擎加載到正在運新的MySQL伺服器中。

本章介紹了插件式儲存引擎體系結構,概要介紹了與MySQL一起提供的各種儲存引擎,介紹了將儲存引擎賦給資料表的方法,以及插入和拔出儲存引擎的方法。


14.2. 概述


使用MySQL插件式儲存引擎體系結構,允許資料庫專業人員為特定的應用需求選擇專門的儲存引擎,完全不需要管理任何特殊的應用編碼要求。採用MySQL伺服器體系結構,由於在儲存級別上提供了一致和簡單的應用模型和API,應用程式編程人員和DBA可不再考慮所有的底層實施細節。因此,儘管不同的儲存引擎具有不同的能力,應用程式是與之分離的。

在下圖中,以圖形方式介紹了MySQL插件式儲存引擎體系結構:

圖14.1:MySQL插件式儲存引擎的體系結構
The MySQL pluggable storage engine architecture

插件式儲存引擎體系結構提供了標準的管理和支援服務集合,它們對所有的基本儲存引擎來說是共同的。儲存引擎本身是資料庫伺服器的組件,負責對在物理伺服器層面上維護的基本數據進行實際操作。

這是一種高效的模塊化體系結構,它為那些希望專注於特定應用需求的人員提供了巨大的便利和益處,這類特殊應用需求包括數據倉儲、事務處理、高可用性情形等,同時還能利用獨立於任何儲存引擎的一組接口和服務。

應用程式編程人員和DBA通過位於儲存引擎之上的連接器API和服務層來處理MySQL資料庫。如果應用程式的變化需要改變底層儲存引擎,或需要增加1個或多個額外的儲存引擎以支援新的需求,不需要進行大的編碼或程序更改就能實現這類要求。MySQL伺服器體系結構提供了一致和易於使用的API,這類API適用於多種儲存引擎,通過該方式,該結構將應用程式與儲存引擎的底層複雜性隔離開來。


14.3. 公共MySQL資料庫伺服器層


MySQL插件式儲存引擎是MySQL資料庫伺服器中的組件,負責為資料庫執行實際的數據I/O操作,並能允許和強制執行面向特殊應用需求的特定特性集合。使用特殊儲存引擎的主要優點之一在於,僅需提供特殊應用所需的特性,因此,資料庫中的系統開銷較小,最終結果具有更有效和更高的資料庫性能。這也是MySQL被始終視為具有高性能的原因之一,在行業標準基準方面,它能匹敵或擊敗專有的整體式資料庫。

從技術角度上看,在儲存引擎中,一些獨特的支援底層結構的組件是什麼呢?一些關鍵差別包括:
  • 並發性:某些應用程式比其他應用程式具有很多的顆粒級鎖定要求(如行級鎖定)。選擇正確的鎖定策略能夠減少開銷,並有助於整體性能的提升。它還包括對多種能力的支援,如多版本並發性控制或「快照」讀取等。
  • 事務支援:並非所有的應用程式都需要事務,但對的確需要事務的應用程式來說,有著定義良好的需求,如ACID兼容等。
  • 引用完整性:通過DDL定義的外部鍵,伺服器需要強制保持關聯資料庫的引用完整性。
  • 物理儲存:它包括各種各樣的事項,從資料表和索引的總的頁大小,到儲存數據所需的格式,到物理磁盤。
  • 索引支援:不同的應用程式傾向於採用不同的索引策略,每種儲存引擎通常有自己的編制索引方法,但某些索引方法(如B-tree索引)對幾乎所有的儲存引擎來說是共同的。
  • 內存高速緩衝:與其他應用程式相比,不同的應用程式對某些內存高速緩衝策略的響應更好,因此,儘管某些內存高速緩衝對所有儲存引擎來說是共同的(如用於用戶連接的高速緩衝,MySQL的高速查詢高速緩衝等),其他高速緩衝策略僅當使用特殊的儲存引擎時才唯一定義。
  • 性能幫助:包括針對並行操作的多I/O線程,線程並發性,資料庫檢查點,成批插入處理等。
  • 其他目標特性:可能包括對地理空間操作的支援,對特定數據處理操作的安全限制等。
每組插件式儲存引擎基本組件均採用了相應的設計,能夠為特定應用提供可選擇的特性集合。從反面角度看,避免使用組件特性集合有助於避免不必要的開銷。因此,顯而易見,應理解特定應用程式的需求集合,並選擇恰當的能大幅度改善系統整體效率和性能的MySQL儲存引擎。


14.4. 選擇儲存引擎


與MySQL一起提供的各種儲存引擎在設計時考慮了不同的使用情況。為了更有效地使用插件式儲存體系結構,最好瞭解各種儲存引擎的優點和缺點。

在下面的資料表格中,概要介紹了與MySQL一起提供的儲存引擎:

圖14.2:儲存引擎比較
Storage engine comparison

下述儲存引擎是最常用的:
  • MyISAM:預設的MySQL插件式儲存引擎,它是在Web、數據倉儲和其他應用環境下最常使用的儲存引擎之一。注意,通過更改STORAGE_ENGINE配置變數,能夠方便地更改MySQL伺服器的預設儲存引擎。
  • InnoDB:用於事務處理應用程式,具有眾多特性,包括ACID事務支援。
  • BDB:可替代InnoDB的事務引擎,支援COMMIT、ROLLBACK和其他事務特性。
  • Memory:將所有數據保存在RAM中,在需要快速搜尋引用和其他類似數據的環境下,可提供極快的訪問。
  • Merge:允許MySQL DBA或開發人員將一系列等同的MyISAM資料表以邏輯方式組合在一起,並作為1個對象引用它們。對於諸如數據倉儲等VLDB環境十分適合。
  • Archive:為大量很少引用的歷史、歸檔、或安全審計訊息的儲存和檢索提供了完美的解決方案。
  • Federated:能夠將多個分離的MySQL伺服器連結起來,從多個物理伺服器建立一個邏輯資料庫。十分適合於分佈式環境或數據集市環境。
  • Cluster/NDB:MySQL的叢集式資料庫引擎,尤其適合於具有高性能搜尋要求的應用程式,這類搜尋需求還要求具有最高的正常工作時間和可用性。
  • Other:其他儲存引擎包括CSV(引用由逗號隔開的用作資料庫資料表的檔案),Blackhole(用於臨時禁止對資料庫的應用程式輸入),以及Example引擎(可為快速建立定制的插件式儲存引擎提供幫助)。
請記住,對於整個伺服器或方案,您並不一定要使用相同的儲存引擎,您可以為方案中的每個資料表使用不同的儲存引擎,這點很重要。

關於MySQL中所包含儲存引擎的詳細訊息,請參見14.4節,「選擇儲存引擎」




14.5. 將儲存引擎指定給資料表


可以在建立新資料表時指定儲存引擎,或通過使用ALTER TABLE語句指定儲存引擎。

要想在建立資料表時指定儲存引擎,可使用ENGINE參數:
CREATE TABLE engineTest(
    id INT
) ENGINE = MyISAM;


要想更改已有資料表的儲存引擎,可使用ALTER TABLE語句:
ALTER TABLE engineTest ENGINE = ARCHIVE;


14.6. 儲存引擎和事務


下述儲存引擎支援事務:
  • InnoDB:通過MVCC支援事務,允許COMMIT、ROLLBACK和保存點。
  • NDB:通過MVCC支援事務,允許COMMIT和ROLLBACK。
  • BDB:支援事務,允許COMMIT和ROLLBACK。


14.7. 插入儲存引擎


能夠使用儲存引擎之前,必須使用INSTALL PLUGIN語句將儲存引擎plugin(插件)裝載到mysql。例如,要想加載example引擎,首先應加載ha_example.so模塊:
INSTALL PLUGIN ha_example SONAME 'ha_example.so';

檔案.so必須位於MySQL伺服器庫目錄下(典型情況下是installdir/lib)。


14.8. 拔出儲存引擎


要想拔出儲存引擎,可使用UNINSTALL PLUGIN語句:
UNINSTALL PLUGIN ha_example;

如果拔出了正被已有資料表使用的儲存引擎,這些資料表將成為不可訪問的。拔出儲存引擎之前,請確保沒有任何資料表使用該儲存引擎。


14.9. 插件式儲存器的安全含義


為了安裝插件式儲存引擎,plugin檔案必須位於恰當的MySQL庫目錄下,而且發出INSTALL PLUGIN語句的用戶必須具有SUPER權限。


這是MySQL參考手冊的翻譯版本,關於MySQL參考手冊,請訪問dev.mysql.com。原始參考手冊為英文版,與英文版參考手冊相比,本翻譯版可能不是最新的。
2013-06-10 23:38

[轉載] Google Lerry Page 訂立的開會原則 - 2012

轉載自:Google Lerry Page 訂立的開會原則 - 2012

Google 換 Larry Page 當新的 CEO 後, Larry Page 改變了 Google 的開會流程, 定義了開會所需要注意的幾點事項.

Google 訂立開會原則 - Larry Page


內容參考整理自下述兩篇:

Google 訂立的開會原則

  1. 每次開會都要有一個明確的決策者,如果沒有決策者,或沒法作出決定,就不應該開會議。
    (Every meeting must have one clear decision maker. If there's no decision maker -- or no decision to be made -- the meeting shouldn't happen.)
  2. 開會不能超過10個人。
    (No more than 10 people should attend.)
  3. 每個參與會議者都必須要給出自己的想法、意見,否則不應該參加此次的會議。
    (Every person should give input, otherwise they shouldn't be there.)
  4. 任何要訂立的決策都不應該因為會議未招開而延後。如果需要開會才能做出某個決定,那麼該會議應該立刻招開。
    (No decision should ever wait for a meeting. If a meeting absolutely has to happen before a decision should be made, then the meeting should be scheduled immediately.)
2013-06-05 22:58

[轉載][MySQL] 修復工具 mysqlcheck

轉載自:mysql修复工具mysqlcheck

mysqlcheck -a -c -o -r -m --all-databases -uroot -p

即可最佳化所有db
參數含意:
  • -a = Analyse given tables.
  • -c = Check table for errors
  • -o = Optimise table
  • -r = Can fix almost anything except unique keys that aren't unique
  • -m = --medium-check


mysqlcheck 客戶端可以檢查和修復 MyISAM 資料表。它還可以優化和分析資料表。

mysqlcheck 的功能類似 myisamchk,但其工作不同。主要差別是當 mysqld 服務器在運行時必須使用mysqlcheck,而 myisamchk 應用於服務器沒有運行時。使用 mysqlcheck 的好處是不需要停止服務器來檢查或修復資料表。使用 myisamchk 修復失敗是不可逆的

Mysqlcheck 為用戶提供了一種方便的使用 SQL 語句 CHECK TABLE、REPAIR TABLE、ANALYZE TABLE和OPTIMIZE TABLE 的方式。它確定在要執行的操作中使用使用哪個語句,然後將語句發送到要執行的服務器上。


有3種方式來調用mysqlcheck:
shell> mysqlcheck [options] db_name [tbl_name ...]
shell> mysqlcheck [options] --databases db_name ...
shell> mysqlcheck [options] --all-databases

如果沒有指定任何資料表或使用 --databases 或 --all-databases 選項,則檢查整個數據庫。

同其它客戶端比較,mysqlcheck 有一個特殊特性。重新命名二進制可以更改檢查資料表的默認行為(--check)。如果你想要一個工具默認可以修復資料表的工具,只需要將 mysqlcheck 重新復制為 mysqlrepair,或者使用一個符號鏈接 mysqlrepair 鏈接 mysqlcheck。如果調用 mysqlrepair,可按照命令修復資料表。


下面的名可用來更改 mysqlcheck 的默認行為:
mysqlrepair默認選項為 --repair
mysqlanalyze默認選項為 --analyze
mysqloptimize默認選項為 --optimize


mysqlcheck支持下面的選項:
-A, --all-databases
檢查所有數據庫中的所有資料表。與使用---database選項相同,在命令行中命名所有數據庫。
-a, --analyze
分析資料表。
-1, --all-in-1
不是為每個表發出一個語句,而是為命名數據庫中待處理的所有表的每個數據庫執行一個語句。
--auto-repair
如果某個被檢查的表破壞了,自動修復它。檢查完所有表後自動進行所有需要的修復。
--character-sets-dir=name
字符集的安裝目錄。參見5.10.1節,"數據和排序用字符集"。
-c, --check
檢查資料表的錯誤。
-C, --check-only-changed
只檢查上次檢查以來已經更改的或沒有正確關閉的資料表。
--compress
壓縮在客戶端和服務器之間發送的所有信息(如果二者均支持壓縮)。
-B, --databases
處理數據庫中命名的所有資料表。使用該選項,所有字名參量被看作數據庫名,而不是資料表名稱。
-#, --debug[=#]
寫調試日誌。 debug_options字符串通常為'd:t:o,file_name'。
--default-character-set=name
使用charsetas默認字符集。參見5.10.1節,"數據和排序用字符集"。
-F, --fast
只檢查沒有正確關閉的資料表。
-f, --force
即使出現SQL錯誤也繼續。
-e, --extended
如果你正使用該選項來檢查資料表,可以確保它們100%地一致,但需要很長的時間。 如果你正使用該選項來修復資料表,則運行擴展修復,不但執行的時間很長,而且還會產生大量的垃圾行!
-?, --help
顯示幫助消息並退出。
-h, --host=name
連接給定主機上的MySQL服務器。
-m, --medium-check
執行比--extended操作更快的檢查。只能發現99.99%的錯誤,在大多數情況下這已經足夠了。
-o, --optimize
優化資料表。
-p, --password[=name]
當連接服務器時使用的密碼。如果使用短選項形式(-p),選項和密碼之間不能有空格。 如果在命令行中--password或-p選項後面沒有密碼值,則提示輸入一個密碼。
-P, --port=#
用於連接的TCP/IP端口號。
--protocol=name
使用的連接協議。
-q, --quick
如果你正使用該選項在檢查資料表,它防止掃描行以檢查錯誤鏈接的檢查。這是最快的檢查方法。 如果你正使用該選項在修復資料表,它嘗試只修復索引樹。這是最快的修復方法。
-r, --repair
執行可以修復大部分問題的修復,只是唯一值不唯一時不能修復。
-s, --silent
沉默模式。只打印錯誤消息。
-S, --socket=name
用於連接的套接字文件。
--tables
覆蓋---database或-B選項。選項後面的所有參量被視為資料表名稱。
-u, --user=name
當連接服務器時使用的MySQL用戶名。
-v, --verbose
冗長模式。打印關於各階段程序操作的信息。
-V, --version
顯示版本信息並退出。
2013-06-04 23:14

[PHP] 分配上傳檔案的路徑

<?php

/*數字方式分配路徑*/
function allotPath($id, $extend='jpg') {
    $folders = str_split(sprintf("%012s", $id),3);
    $folders[3] = $id;

    return  '/'. join('/', $folders).'.'.$extend;
}

/*雜湊方式分配路徑*/
function allotHashPath($id, $extend='jpg') {
    $folders = array_slice( str_split(md5($id),2), 0, 4);
    $folders[] = $id;

    return  '/'. join('/', $folders).'.'.$extend;
}

var_dump(allotPath(122333));
// string(23) "/000/000/122/122333.jpg"

var_dump(allotHashPath(122333));
// string(23) "/9c/7c/c2/cd/122333.jpg"

2013-06-04 22:39

[轉載][CSS] 3D 立體文字

轉載自:3D Text

3D 立體文字


h1.title_3d { 
    color: #FFFFFF;
    font: bold 50px/1 "Helvetica Neue",Helvetica,Arial,sans-serif;
        
    text-shadow: 
        0 1px 0 #ccc, 
        0 2px 0 #c9c9c9, 
        0 3px 0 #bbb, 
        0 4px 0 #b9b9b9,
        0 5px 0 #aaa, 
        0 6px 1px rgba(0,0,0,.1), 
        0 0 5px rgba(0,0,0,.1), 
        0 1px 3px rgba(0,0,0,.3), 
        0 3px 5px rgba(0,0,0,.2), 
        0 5px 10px rgba(0,0,0,.25), 
        0 10px 10px rgba(0,0,0,.2), 
        0 20px 20px rgba(0,0,0,.15); 
} 

2013-06-04 22:24

[轉載] 有關程式的佳句

轉載自:忘記了
  • 上聯:插中有插常常插;下聯:一錯再錯都是錯;橫批:誰寫的爛程式!?
  • 防呆機制就是用你現在的五分鐘,換取以後你可能會用來補救的五十分鐘。
  • 就算開發效率再快,執行的結果不對的話就都是個屁。
  • 將功能切細,才能獲得組合的彈性。
  • 好的程式語言在設計上需要周密,在開發上需要簡化。
  • 有時愛情就像潛水一樣,愛得越深,壓力越大;沒毅力的人很快地就想要浮上水面喘口氣,執著的人卻是粉身碎骨葬身海底。
  • 有些系統就像森林裡的石頭一樣…一翻開來看底下都是蟲。
  • 所謂的大師,就是透徹某些技術的精髓,然後以最精簡的話語,來表達他的想法。
  • Reuse 就是 Copy 一行程式跟 Copy 十行程式的差別。
  • 高手包裝部份程式然後複製一行,新手複製整個程式然後修改一行。
  • 能傷害別人的武器,必定也能傷害自己。
  • 程式開發不成文定律:判斷式越多, Bug 也越多。
  • 少點抱怨就能多點專業。
  • 專業:就是從不在意不愉快的事開始,然後把心思放在該解決的事情上。
  • 只有當你透徹這項技術時,你才能坐在評審的位置。
  • 切入問題的角度,決定解決問題的速度。
  • 在 PHP 中,有時簡單的陣列,可以取代複雜的類別;簡單來說,就是不要捨近求遠。
2013-06-04 21:49

[轉載] HTTP 狀態碼

轉載自:HTTP 狀態碼 - 網站管理員工具說明

當向您的伺服器傳送一個要求,要求顯示您網站的網頁 (例如,在使用者在瀏覽器中存取您的網頁,或 Googlebot 檢索該網頁時),則您的伺服器會傳回 HTTP 狀態碼,以回應該要求。

此狀態碼會提供有關該要求的狀態的資訊。此狀態碼會向 Googlebot 提供有關您的網站和所要求的網頁的資訊。

以下為一些常見的狀態碼:

  • 200 - 伺服器成功傳回網頁
  • 404 - 找不到所要求的網頁
  • 503 - 伺服器暫時無法使用

以下是 HTTP 狀態碼的完整清單。您還可以瀏覽有關 HTTP 狀態碼的 W3C 網頁,以取得更多資訊


1xx (Provisional response)
指出暫時回應並需要要求者採取措施以繼續的狀態碼。

  • 100 (Continue)
    要求者應當繼續此要求。伺服器傳回此代碼,指出已收到某個要求的第一部分,正等候其餘部分。
  • 101 (Switching protocols)
    要求者已請求伺服器切換通訊協定,伺服器正在確認即將進行切換。

2xx (Successful)
指出伺服器已成功處理該要求的狀態碼。

  • 200 (Successful)
    伺服器已成功處理該要求。一般而言,這代表伺服器已提供所要求的網頁。如果您在 robots.txt 檔案中看到此狀態,即表示 Googlebot 已成功擷取該網頁。
  • 201 (Created)
    該要求已成功完成,伺服器已建立新的資源。
  • 202 (Accepted)
    伺服器已接受該要求,但尚未處理。
  • 203 (Non-authoritative information)
    伺服器成功處理該要求,但正在傳回可能來自另一來源的資訊。
  • 204 (No Content)
    伺服器已成功處理該要求,但沒有傳回任何內容。
  • 205 (Reset Content)
    伺服器已成功處理該要求,但沒有傳回任何內容。與 204 回應不同,此回應需要要求者重設文件視圖 (例如,清除表單,以輸入新的資料)。
  • 206 (Partial Content)
    伺服器已成功處理部分 GET 要求。

3xx (Redirected)
您需要採取進一步的動作才能完成該要求。通常這些狀態碼會用來重新導向。Google 建議每個要求不要使用超過五次重新導向。您可以使用「網站管理員工具」來查看 Googlebot 在檢索重新導向的網頁時是否存在問題。在 [健康狀態] 下的「檢索錯誤」網頁會列出 Googlebot 因重新導向錯誤而無法檢索的網址。

  • 300 (Multiple Choices)
    根據該要求,伺服器可採取數種動作。伺服器可能會根據要求者 (user-agent) 選擇一個動作,或者可能列出清單供要求者選擇一個動作。
  • 301 (Moved Permanently)
    要求的網頁已永久移到新位置。當伺服器傳回此回應 (作為對 GET 或 HEAD 要求的回應) 時,會自動將要求者導向至新位置。您應該使用此代碼,讓 Googlebot 知道某個網頁或網站已永久移至新位置。
  • 302 (Moved Temporarily)
    伺服器目前正對來自不同位置的網頁回應該要求,但是要求者應該繼續使用原位置發出以後的要求。此代碼類似於回應 GET 或 HEAD 要求的 301 代碼,會自動將要求者導向至另一個位置,但是因為 Googlebot 會繼續檢索原位置並為其建立索引,所以您不應該使用此代碼來告知 Googlebot 某個網頁或網站已移除。
  • 303 (See Other Location)
    當要求者應該對另一個位置發出單獨的 GET 要求以擷取回應時,伺服器會傳回此代碼。對於 HEAD 之外的所有要求,伺服器會自動導向至其他位置。
  • 304 (Not Modified)
    要求的網頁自上次要求以後未經任何修改。當伺服器傳回此回應時,並不會傳回該網頁的內容。
    如果網頁自要求者上次要求以後,未經任何修改,則您應該設定伺服器傳回此回應 (稱為 If-Modified-Since HTTP 標頭)。這樣可以節省您的頻寬和負載,因為您的伺服器可以告知 Googlebot 網頁自上次檢索後,未經任何修改.
  • 305 (Use Proxy)
    要求者只能使用 Proxy 存取要求的網頁。當伺服器傳回此回應時,還會指出要求者應該使用的 Proxy。
  • 307 (Temporary Redirect)
    伺服器目前正對來自不同位置的網頁回應該要求,但是要求者應該繼續使用原位置發出以後的要求。此代碼類似於回應 GET 或 HEAD 要求的 301 代碼,會自動將要求者導向至另一個位置,但是因為 Googlebot 會繼續檢索原位置並為其建立索引,所以您不應該使用此代碼來告知 Googlebot 某個網頁或網站已移除。

4xx (Request Error)
這些狀態碼指出要求中可能存在使伺服器無法進行處理的錯誤。

  • 400 (Bad Request)
    伺服器無法解讀該要求的語法。
  • 401 (Not Authorized)
    該要求需要驗證。登入後,伺服器可能會對網頁傳回此回應。
  • 403 (Forbidden)
    伺服器拒絕要求。如果您看到 Googlebot 在嘗試檢索您網站的有效網頁時收到這個狀態碼 (您可以在 Google 網站管理員工具 [健康狀態] 標籤下的「檢索錯誤」網頁中看到這狀態碼),則可能是因為您的伺服器或主機封鎖了 Googlebot 的存取權。
  • 404 (Not found)
    伺服器找不到要求的網頁。例如,如果該要求是針對伺服器上不存在的網頁,則伺服器通常會傳回此代碼。
    如果您的網站上沒有 robots.txt 檔案,並在 Google 網站管理員工具的「封鎖的網址」網頁看到這個狀態,則這個狀態是正確的。不過,如果您有 robots.txt 檔案,並看到此狀態,則您的 robots.txt 檔案可能未正確命名或位於錯誤的位置。(應該位於網域的最高層級並且命名為 robots.txt)。
    如果您在 Googlebot 嘗試檢索的網址中看到這個狀態,則 Googlebot 所追蹤的很可能是來自其他網頁的無效連結 (可能是舊連結或拼字錯誤的連結)。
  • 405 (Method Not Allowed)
    不允許要求中指定的方法。
  • 406 (Not Acceptable)
    無法以所要求的內容特性回應要求的網頁。
  • 407 (Proxy Authentication Required)
    此狀態碼類似於 401(Not Authorized),但指定要求者必須使用 Proxy 進行驗證。當伺服器傳回此回應時,還會指出要求者應該使用的 Proxy。
  • 408 (Request Timeout)
    等候回應時,發生伺服器逾時。
  • 409 (Conflict)
    完成要求時,伺服器遇到衝突。伺服器必須包括有關在回應中的衝突的資訊。伺服器可能會在 PUT 要求與較早的某個要求相衝突時傳回此狀態碼作為回應,並會提供這兩個要求之間的差異清單。
  • 410 (Gone)
    要求的資源已永久移除後,伺服器會回傳此回應。此代碼類似於 404 (Not Found) 代碼,但在資源曾經存在但現已不復存在的情況下,有時會取代 404 而使用。如果資源已永久遷移,則應使用 301 指定資源的新位置。
  • 411 (Length Required)
    伺服器不接受不含有效內容長度不標頭欄位的要求。
  • 412 (Precondition Failed)
    伺服器未滿足要求者所要求的其中一個前提。
  • 413 (Request Entity Too Large)
    伺服器無法處理要求,因為要求過於龐大,伺服器無法處理。
  • 414 (Requested URI Is Too Long)
    要求的 URI (通常是網址) 過長,伺服器無法處理。
  • 415 (Unsupported Media Type)
    該要求的格式不受要求的網頁支援。
  • 416 (Requested Range Not Satisfiable)
    如果該要求是針對該網頁上無法使用的範則,則伺服器便會傳回此狀態碼。
  • 417 (Expectation Failed)
    伺服器無法滿足預期要求標頭欄位的要求。

5xx (Server Error)
這些狀態碼指出伺服器在嘗試處理要求時發生內部錯誤。這些錯誤可能是伺服器本身的錯誤,而不是要求的錯誤。

  • 500 (Internal Server Error)
    伺服器遇到錯誤,無法完成要求。
  • 501 (Not Implemented)
    伺服器不具備完成要求所需的功能。例如,當伺服器無法識別要求方式時,就會傳回此代碼。
  • 502 (Bad Gateway)
    伺服器用作閘道或 Proxy,接收到來自上游伺服器的無效回應。
  • 503 (Service unavailable)
    伺服器目前暫時無法使用 (因為超載或維護之故而關閉)。一般而言,這是暫時性狀態。
  • 504 (Gateway Timeout)
    伺服器用作閘道或 Proxy,而且未接收到來自上游伺服器的及時要求。
  • 505 (HTTP Version Not Supported)
    伺服器不支援要求中所用的 HTTP 通訊協定版本。