面試雜碎01

一、http狀態碼

1**：信息，服務器收到請求，須要請求者繼續執行操做

2**：成功，操做被成功接收並處理

3**：重定向，須要進一步的操做以完成請求

4**：客戶端錯誤，請求包含語法錯誤或沒法完成請求

5**：服務器錯誤，服務器在處理請求的過程當中發生了錯誤

從輸入URL按下回車到頁面展示,總的來講發生了一下幾個過程：

DNS 解析:將域名解析成 IP 地址
TCP 鏈接：TCP 三次握手
發送 HTTP 請求
服務器處理請求並返回報文
瀏覽器解析渲染頁面
斷開鏈接：TCP 四次揮手

1.說一下http和https
http:http是最爲普遍應用的互聯網傳輸協議，即超文本傳輸協議。HTTP是一個屬於應用層的面向
對象的協議。因爲其簡捷、快速的方式，適用於分佈式超媒體信息系統。

簡介：超文本傳輸協議，
1)http是最爲普遍引用的互聯網傳輸協議，https是http的安全版，它的安全基礎是SSL加密傳輸協議
2)http是明文傳輸的，傳送報文容易被黑客截取
3)https須要到CA申請證書，能夠認證客戶端和服務端，確保正確發送到客戶端和服務器
4)http和https使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是80，後者是443。（
Http：超文本傳輸協議（Http，HyperText Transfer Protocol)是互聯網上應用最
爲普遍的一種網絡協議。設計Http最初的目的是爲了提供一種發佈和接收HTML
頁面的方法。它可使瀏覽器更加高效。Http協議是以明文方式發送信息的，若是黑客截取了
Web瀏覽器和服務器之間的傳輸報文，就能夠直接得到其中的信息。
5)Https協議的加密範圍也比較有限。最關鍵的，SSL證書的信用鏈體系並不安全
6)http效率更高，https須要綁定ip,https並不是絕對安全

二、tcp三次握手，一句話歸納
第一次握手：客戶端向移動端發送鏈接請求
第二次握手：服務端收到請求，向客戶端進行反饋
第三次握手：第二次握手後，客戶端確認當前請求是否繼續有效

三、TCP和UDP的區別
TCP是一種面向鏈接的、可靠的、基於字節流的傳輸層通訊協議；UDP是
一種無鏈接的傳輸層協議，提供面向事務的簡單不可靠信息傳送服務
TCP面向鏈接（如打電話要先撥號創建鏈接）;
UDP是無鏈接的，即發送數據以前不須要創建鏈接
TCP提供可靠的服務。也就是說，經過TCP鏈接傳送的數據，
無差錯，不丟失，不重複，且按序到達;UDP盡最大努力交付，
即不保證可靠交付
Tcp經過校驗和，重傳控制，序號標識，滑動窗口、
確認應答實現可靠傳輸。如丟包時的重發控制，還能夠對次序亂掉的分包進行順序控制。
UDP具備較好的實時性，工做效率比TCP高，
適用於對高速傳輸和實時性有較高的通訊或廣播通訊。
每一條TCP鏈接只能是點到點的;UDP支持一對一，
一對多，多對一和多對多的交互通訊
TCP對系統資源要求較多，UDP對系統資源要求較少。

四、WebSocket的實現和應用
WebSocket 是 HTML5 開始提供的一種在單個 TCP 鏈接上進行全雙工通信的協議。
Websocket是一個持久化的協議，相對於HTTP這種非持久的協議來講。
HTTP的生命週期經過 Request 來界定，
也就是一個 Request 一個 Response ，那麼在 HTTP1.0 中，此次HTTP請求就結束了。
應用:ajax輪詢(異步) long poll(阻塞)
服務端就能夠主動推送信息給客戶端，只須要通過一次HTTP請求，就能夠作到源源不斷的信息傳送了

8. 幾個很實用的BOM屬性對象方法?

window.navigator/location/history
九、兼容前綴
-webkit-　　　　　　chrome、safari

-moz-　　　　　　　 firefox

-ms- IE

-o- opera
10. 說一下http2.0/http1.1/http1.0
http1.0:無狀態無鏈接。無鏈接指每次鏈接只處理一個請求，無狀態是指協議對於事務處理沒有記憶能力
http1.1:持久鏈接
請求管道化
一般，http請求老是順序發送的，下一個請求只有在當前請求的響應被徹底接受的時候纔會被髮送。因爲網絡延遲和帶寬的限制，這樣會致使在服務器發送下一個響應的時候中間有很大的延遲。
HTTP/1.1 容許多個http請求經過一個套接字同時被輸出 ，而不用等待相應的響應。而後請求者就會等待各自的響應，這些響應是按照以前請求的順序依次到達。
增長緩存處理（新的字段如cache-control）
增長Host字段、支持斷點傳輸等（把文件分紅幾部分）
在HTTP/1.1中請求頭已經默認使用Connection: keep-alive，避免了鏈接創建
和釋放的開銷，但服務器必須按照客戶端請求的前後順序依次回送相應的
結果，以保證客戶端可以區分出每次請求的響應內容。
http2.0:二進制分幀
多路複用（或鏈接共享）
全部的HTTP2.0通訊都在一個TCP鏈接上完成，這個鏈接能夠承載任意數量的雙向數據流。
頭部壓縮
服務器推送

11. 補充400和40一、403狀態碼
400：服務器不理解請求的語法。
401：沒有經過身份驗證
403：服務器拒絕訪問
404：服務器上找不到所請求的資源

13. Cookie、sessionStorage、localStorage的區別
Cookie有數量和大小（4kb)的限制，且須要咱們自行封裝api
須要指定做用域。容易被篡改，不安全
webStorage
分爲sessionStorage 和 localStorage
WebStorage並不做爲HTTP header發送到瀏覽器，因此相對安全
sessionStorage在會話結束後刪除，localStorage是持久化存儲，若不主動刪除
，則永久有效。
有本身的api。5mb建議大小

14. 說一下web worker
Web Worker 的做用，就是爲 JavaScript 創造多線程環境，
容許主線程建立 Worker 線程，將一些任務分配給後者運行。

16. iframe是什麼？有什麼缺點？
iframe也稱做嵌入式框架，嵌入式框架和框架網頁相似，它能夠把一個網頁的框架和內容嵌入在現有的網頁中。
iframe標籤的一些基本屬性：
src iframe頁面地址，有同域跨域之分
height iframe高度
width iframe寬度
name iframe命名，可經過window.frames[xxx]被調用
scrolling iframe滾動模式
sandbox html5新特性，用於限制iframe的功能

咱們能夠經過contentWindow和contentDocument兩個API獲取iframe的window對象和document對象。

iframe缺點：產生不少頁面，不容易管理
iframe框架頁面會增長服務器的http請求
代碼複雜，不利於SEO
瀏覽器的後退按鈕無效

17. Doctype做用?嚴格模式與混雜模式如何區分？它們有何意義?
告訴瀏覽器以何種規範解析文檔
嚴格模式：又稱標準模式，是指瀏覽器按照 W3C 標準解析代碼。
混雜模式：又稱怪異模式或兼容模式，是指瀏覽器用本身的方式解析代碼
沒有正確聲明DTD或者加入xml聲明將觸發混雜模式

18. Cookie如何防範XSS攻擊
XSS, 即爲（Cross Site Scripting）, 中文名爲跨站腳本, 是
發生在目標用戶的瀏覽器層面上的，當渲染DOM樹的過程成發生了不在預
期內執行的JS代碼時，就發生了XSS攻擊。

設置了HttpOnly屬性的cookie變量沒法被js獲取，能夠避免此種攻擊

20、
RESTful是一種架構風格、設計風格，基
於RESTful的web系統更有層次、簡便、輕量級以及經過HTTP直接傳輸，
RESTful web服務成爲替代SOAP服務的一個更有前途的替代方案。

2六、iframe通訊，同源和不一樣源兩種狀況
同域：即父子頁面相互調用
1、父頁面調用子頁面
一、先獲得子頁面的document
document.getElementById('FrameId').contentWindow.document
二、獲得子頁面的window
document.getElementById('FrameId').contentWindow.window
重載子頁面：document.getElementById('FrameId').contentWindow.window.location.reload(true);
或者 $('#FrameId').attr('src','../list');
三、獲得子頁面的的變量
doucment. iframe的name屬性值 . 子頁面變量名稱 （document.frameName.temp）
2、子頁面調用父頁面
一、父頁面document ： window.parent.document
二、得到父頁面變量 ： parent.變量名稱
三、調用事件 ： window.parent.XXX();

跨域：
主域：由兩個或兩個以上的字母構成，中間由點號隔開，整個域名只有1個點號
csdn.net
子域：是在主域名之下的域名，域名內容會有多個點號

未跨主域，跨子域
兩個域的js文件中設置document.domain=主域名 便可

跨主域
location.hash
(B操做A)
一、動態改變location.hash，iframe不會重載
二、不管跨域與否，iframe內能夠獲取本身的location.hash
三、只要域名相同就能通訊，即便ABC三層嵌套

 

2七、介紹知道的http返回的狀態碼
2開頭的http狀態碼
表示請求成功
200 成功處理了請求，通常狀況下都是返回此狀態碼；

3xx （重定向）
重定向代碼，也是常見的代碼
301 （永久移動） 請求的網頁已永久移動到新位置。 服務器返回此響應（對 GET 或 HEAD 請求的響應）時，會自動將請求者轉到新位置。
302 （臨時移動） 服務器目前從不一樣位置的網頁響應請求，但請求者應繼續使用原有位置來進行之後的請求。
304 （未修改） 自從上次請求後，請求的網頁未修改過。 服務器返回此響應時，不會返回網頁內容。

4開頭的http狀態碼錶示請求出錯
400 服務器不理解請求的語法。
401 請求要求身份驗證。 對於須要登陸的網頁，服務器可能返回此響應。
403 服務器拒絕請求。
404 服務器找不到請求的網頁。

5開頭狀態碼並不常見，可是咱們應該知道
500 （服務器內部錯誤） 服務器遇到錯誤，沒法完成請求。

2八、http經常使用請求頭
Cache-Control 設置請求響應鏈上全部的緩存機制必須遵照的指令
Connection 設置當前鏈接和hop-by-hop協議請求字段列表的控制選項
Content-Type 設置請求體的MIME類型（適用POST和PUT請求）
If-Modified-Since 設置更新時間，從更新時間到服務端接受請
求這段時間內若是資源沒有改變，容許服務端返回304 Not Modified
cookie
user-agent:用戶瀏覽器信息

2九、經常使用響應頭
Cache-Control 告訴服務端到客戶端全部的緩存機制是否能夠緩存這個對象，單位是秒
Content-Type 設置響應體的MIME類型
Expires 設置響應體的過時時間
Status 設置HTTP響應狀態

注意：頭文件分爲
general-header ;
general header是request、response均可用的, 可是不能用於entity.
其包含的字段有：
Request URL ：請求的url
Request Method ： 請求的方法，能夠是GET、POST
Status Code：HTTP 狀態碼，表示請求成功
Remote Address：遠程IP地址

request-header ;請求頭
cookie
user-agent:用戶瀏覽器信息
connection:是否創建持久鏈接，http1.1中默認keep-alive創建持久鏈接
Cache-Control：緩存相關，創建請求和響應所遵循的緩存的機制、
Content-Type:請求體的MIME類型 （用於POST和PUT請求中）
If-Modified-Since:緩存相關：若是請求的部分在指定時間以後被修改則請求成功，未被修改則返回304代碼
Accept：客戶端須要接收的mime類型

 

response-header ;響應頭
Last-Modified：緩存相關，返回資源最近一次修改的日期
Expires:緩存相關，響應過時的日期和時間
ETag：請求變量的實體標籤的當前值
Content-Type：響應的mime類型
Cache-Control：告訴全部的緩存機制是否能夠緩存及哪一種類型

 

2九、強，協商緩存
瀏覽器緩存主要分爲強緩存（也稱本地緩存）和協商緩存（也稱弱緩存）
強緩存是利用請求頭中的Expires和Cache-Control兩個字段來控制的，用來表示資源的
緩存時間。強緩存中，普通刷新會忽略它，但不會清除它，須要強制刷新。瀏覽器強制刷新，
請求會帶上Cache-Control:no-cache和Pragma:no-cache
Cache-Control:no-cache：不使用本地緩存。須要使用緩存協商
，先與服務器確認返回的響應是否被更改，若是
以前的響應中存在ETag，那麼請求的時候會與服務
端驗證，若是資源未被更改，則能夠避免從新下載

協商緩存就是由服務器來肯定緩存資源是否可用，因此客戶端與服務器端要
經過某種標識來進行通訊，從而讓服務器判斷請求資源是否能夠緩存訪問。
普通刷新會啓用弱緩存，忽略強緩存。只有在地址欄或收藏夾輸入網址、經過連接引用資源等情
況下，瀏覽器纔會啓用強緩存，這也是爲何有時候咱們更新一張圖片、一個js文件，頁面
內容依然是舊的，可是直接瀏覽器訪問那個圖片或文件，看到的內容倒是新的。

3一、講講304
304狀態碼或許不該該認爲是一種錯誤，
而是對客戶端有緩存狀況下服務端的一種響應
在瀏覽器第一次請求某一個URL時，服務器端的返回狀態會是200，
內容是客戶端請求的資源，同時有一個Last-Modified的屬性
標記此文件在服務器端最後被修改的時間。
客戶端第二次請求此URL時，根據HTTP協議的規定，
瀏覽器會向服務器傳送If-Modified-Since報頭，詢問
該時間以後文件是否有被修改過
若是服務器端的資源沒有變化，則自動返回 HTTP 304（Not Ch
anged.）狀態碼，內容爲空，這樣就節省了傳輸數據量。當服務器端
代碼發生改變或者重啓服務器時，則從新發出資源，返回和第
一次請求時相似。
3二、強緩存、協商緩存何時用哪一個

3三、前端優化
1)減小http請求，使用精靈圖
2)使用CDN:
若是應用程序web服務器離用戶更近，那麼一個HTTP請求的響應時間將縮短。另外一方面，若是組件web服務器離用戶更近，則多個HTTP請求的響應時間將縮短。
CDN（內容發佈網絡）是一組分佈在多個不一樣地理位置的Web服務器，
用於更加有效地向用戶發佈內容。在優化性能時，向特定用戶發佈內容的服務
器的選擇基於對網絡慕課擁堵的測量。例如，CDN可能選擇網絡階躍數最小的服務器
，或者具備最短響應時間的服務器。
3)使用瀏覽器緩存
4)壓縮組件
在通常的網站中，靜態資源使用頻率高，流量佔用大。對於訪問量稍大的網站，都會把靜態資源放置到 CDN 服務器，不佔用業務服務器的網絡帶寬，而達到更好的用戶體驗

3四、GET和POST的區別
1)get的請求數據拼接在url內，post的請求數據在請求體內
2)get請求只能進行url編碼，而post支持多種編碼方式
3)
GET產生一個TCP數據包；POST產生兩個TCP數據包。
對於GET方式的請求，瀏覽器會把http header和data一併發送出去，服務器響應200（返回數據）；
而對於POST，瀏覽器先發送header，服務器響應100 continue，瀏覽器再發送data，服務器響應200 ok（返回數據）。

3五、301和302的區別
301是永久重定向。302時暫時重定向

3六、HTTP支持的方法：get/post
4三、常見的HTTP的頭部
5二、描述一下XSS和CRSF攻擊？防護方法？

5四、具體有哪些請求頭是跟緩存相關的
Cache-control if-Modified-Since
響應頭：

5六、cookie有哪些字段能夠設置

5七、cookie有哪些編碼方式？
url編碼

6八、瀏覽器緩存機制
瀏覽器請求某一資源時，會先獲取該資源緩存的header信息，而後根據header中的
Cache-Control和Expires來判斷是否過時。若沒過時則直接從緩存中獲取資源信息，包
括緩存的header的信息，因此這次請求不會與服務器進行通訊。這裏判斷是否過時，則是
強緩存相關。後面會講Cache-Control和Expires相關。

若是顯示已過時，瀏覽器會向服務器端發送請求，這個請求會攜帶第一次請求返回的有
關緩存的header字段信息，好比客戶端會經過If-None-Match頭將先前服務器端發送過
來的Etag發送給服務器，服務會對比這個客戶端發過來的Etag是否與服務器的相同，若相
同，就將If-None-Match的值設爲false，返回狀態304，客戶端繼續使用本地緩存，不解析服
務器端發回來的數據，若不相同就將If-None-Match的值設爲true，返回狀態爲200，客戶
從新機械服務器端返回的數據；客戶端還會經過If-Modified-Since頭將先前服務器端發過來的
最後修改時間戳發送給服務器，服務器端經過這個時間戳判斷客戶端的頁面是不是最新的，若是
不是最新的，則返回最新的內容，若是是最新的，則返回304，客戶端繼續使用本地緩存。

6九、TCP四次揮手
1)客戶端發送關閉請求，再也不向服務端發送請求
2)第二次揮手，服務端已經接收到了客戶端的關閉請求，此時還能夠繼續向客戶端發送信息
3)全部數據發送完畢後，服務端通知客戶端能夠關閉
4)客戶端收到能夠關閉的通知，通知服務端能夠關閉，服務端收到關閉容許後馬上關閉。
客戶端設置定時器，到時間自動關閉

70、爲何鏈接的時候是三次握手，關閉的時候倒是四次握手？
答：由於當Server端收到Client端的SYN鏈接請求報文後，能夠直接發送S
YN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。可是關閉
鏈接時，當Server端收到FIN報文時，極可能並不會當即關閉SOCKET，因此只
能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我
Server端全部的報文都發送完了，我才能發送FIN報文，所以不能一塊兒發送。故須要四步握手。

7一、描述一下XSS和CRSF攻擊？防護方法？
XSS跨站腳本攻擊，發生在客戶端，瀏覽器在解析渲染DOM時執行了意外的JS腳本。XSS漏洞主要是沒有處理好
用戶的輸入而產生的。爲了防範XSS的攻擊，必須爲輸入添加驗有效的驗證，爲cookie設置httpOnly

CSRF跨站請求僞造：
最簡單的方法就是抓取一個正常請求的數據包，去掉Referer字段後再從新提交，若是該提交還有效，那麼基本上能夠肯定存在CSRF漏洞。
驗證 HTTP Referer 字段；在請求地址中添加 token 並驗證；在 HTTP 頭中自定義屬性並驗證。
7二、fetch
1)fetch內部使用promise封裝的
2)fetch()返回的promise將不會拒絕http的錯誤狀態，即便響應是一個HTTP 404或者500
3)在默認狀況下 fetch不會接受或者發送cookies
若是想要在同域中自動發送cookie,加上 credentials 的 same-origin 選項

7三、cookie：其實cookie是一個很小的文本文件，
是瀏覽器儲存在用戶的機器上的。Cookie是純
文本，沒有可執行代碼。儲存一些服務器須要的信息
，每次請求站點，會發送相應的cookie，這些cookie能夠
用來辨別用戶身份信息等做用。
經過docuemnt.cookie能夠設置和獲取Cookie的值

請求行：

①是請求方法，GET和POST是最多見的HTTP方法，除此之外還包括DELETE、HEAD、OPTIONS、PUT、TRACE。
②爲請求對應的URL地址，它和報文頭的Host屬性組成完整的請求URL。
③是協議名稱及版本號。

7五、token
防止表單重複提交，進行身份驗證

7六、fetch發送兩次請求？
緣由很簡單 由於你用的fetch post修改了請求頭,致使fetch第一發送一個o
ptions請求，詢問服務器是否支持修改的請求頭，如過服務器支持，那麼將會再次發送真正的請求。

7七、session/sessionStorage
是不同的兩個東西

7八、session/cookie的區別

Session 對象存儲特定用戶會話所需的屬性及配置信息。這樣，當用戶在應用程序的 Web 頁之
間跳轉時，存儲在 Session 對象中的變量將不會丟失，而是在整個用戶會話中一直存在下去。當用戶
請求來自應用程序的 Web 頁時，若是該用戶尚未會話，則 Web 服務器將自動建立一個 Session 對
象。當會話過時或被放棄後，服務器將終止該會話。
1)cookie保存在瀏覽器端，session保存在服務器端
2)有1)知session比cookie更安全
3)cookie有大小限制，session沒有
4)存儲內容：cookie只能保存字符串類型，以文本的方式；session經過相似與Hashtable的數據結構來保存，
能支持任何類型的對象(session中可含有多個對象)

7九、計算機網絡分爲哪幾層？
TCP/IP :鏈路、網絡、傳輸、應用
鏈路：以二進制的形式在物理層面上傳輸數據，傳輸有地址的幀以及錯誤檢測功能
網絡：爲數據包選擇路由
傳輸：提供端對端的接口
應用：數據格式化，代碼轉換，數據加密，實現文件傳輸，文件服務等功能

 

80、什麼場景使用TCP/UDP？那些應用層使用了UDP？
應用場景
#TCP應用場景
當對網絡通訊質量有要求時，好比：整個數據要準確無誤的傳遞給對方，這每每對於一些要求可靠的應用，好比HTTP,HTTPS,FTP等傳輸文件的協議，POP,SMTP等郵件的傳輸協議。常見使用TCP協議的應用：
1.瀏覽器使用的：HTTP
2.FlashFXP:FTP
3.Outlook:POP，SMTP
4.QQ文件傳輸

UDP 文件傳輸協議
對當前網絡通信質量要求不高的時候，要求網絡通信速度儘可能的快，這時就使用UDP
平常生活中常見使用UDP協議：
1.QQ語音
2.QQ視頻
3.TFTP

 

8一、DNS

即域名系統。因特網上做爲域名和IP地址相互映射的一個分佈式數據庫，可以使用戶更方便的訪問互聯網，

而不用去記住可以被機器直接讀取的IP數串。

經過主機名，最終獲得該主機名對應的IP地址的過程叫作域名解析（或主機名解析）

一、瀏覽器中輸入www.qq.com域名，操做系統會先檢查本地的hosts文件是否有這個網址映射關係，

若是有，就先調用這個IP地址映射，完成域名解析。

二、若是hosts裏沒有這個域名的映射，則查找本地DNS解析器緩存，

是否有這個網址映射關係，若是有，直接返回，完成域名解析。

三、若是二者都沒有相應的網址映射關係，首先會找TCP/IP參數中設置的首選DNS服務器，

在此咱們叫它本地DNS服務器，此服務器收到查詢時，若是要查詢的域名，

包含在本地配置區域資源中，則返回解析結果給客戶機，完成域名解析，此解析具備權威性。

四、若是要查詢的域名，不禁本地DNS服務器區域解析，

但該服務器已緩存了此網址映射關係，

則調用這個IP地址映射，完成域名解析，此解析不具備權威性。

五、若是本地DNS服務器本地區域文件與緩存解析都失效，

則根據本地DNS服務器的設置（是否設置轉發器）進行查詢，若是未用轉發模式，

本地DNS就把請求發至13臺根DNS，

根DNS服務器收到請求後會判斷這個域名(.com)是誰來受權管理，

並會返回一個負責該頂級域名服務器的一個IP。

本地DNS服務器收到IP信息後，將會聯繫負責.com域的這臺服務器。

這臺負責.com域的服務器收到請求後，若是本身沒法解析，

它就會找一個管理.com域的下一級DNS服務器地址(qq.com)給本地DNS服務器。

當本地DNS服務器收到這個地址後，就會找qq.com域服務器，

重複上面的動做，進行查詢，直至找到www.qq.com主機。

六、若是用的是轉發模式，此DNS服務器就會把請求轉發至上一級DNS服務器，

由上一級服務器進行解析，上一級服務器若是不能解析，

或找根DNS或把轉請求轉至上上級，以此循環。無論是本地DNS服務器用是是轉發，

仍是根提示，最後都是把結果返回給本地DNS服務器，由此DNS服務器再返回給客戶機。

當瀏覽者訪問一個網頁時，瀏覽者的瀏覽器會向網頁所在服務器發出請求。當瀏覽器接收並顯示網頁前，此網頁所在的服務器會返回一個包含HTTP狀態碼的信息頭（server header）用以響應瀏覽器的請求。

英文版

When a visitor visits a webpage, the browser of the visitor makes a request to the server where the webpage is located. When the browser receives and displays the web page, the server on which the web page resides returns a server header containing the HTTP status code to respond to the browser's request.

http常見的HTTP狀態碼：

200 - 請求成功

301 - 資源（網頁等）被永久轉移到其它URL

404 - 請求的資源（網頁等）不存在

500 - 內部服務器錯誤

英文版

http common HTTP status code:

200 - The request was successful

301 - Resources (web pages, etc.) are permanently transferred to other URLs

404 - The requested resource (webpage, etc.) does not exist

500 - Internal server error

http狀態碼的分類

http狀態碼由三個十進制數字組成，第一個十進制數字定義了狀態碼的類型，後兩個數字沒有分類的做用。HTTP狀態碼共分爲5種類型：分類描述

1**：信息，服務器收到請求，須要請求者繼續執行操做

2**：成功，操做被成功接收並處理

3**：重定向，須要進一步的操做以完成請求

4**：客戶端錯誤，請求包含語法錯誤或沒法完成請求

5**：服務器錯誤，服務器在處理請求的過程當中發生了錯誤

英文版

http status code classification

The http status code consists of three decimal digits. The first decimal digit defines the type of status code. The last two digits have no classification. HTTP status code is divided into 5 types: classification description

1 **: information, the server receives the request, the requester need to continue to operate

2 **: On success, the operation was successfully received and processed

3 **: Redirect, requires further action to complete the request

4 **: client error, request contains a syntax error or can not complete the request

5 **: server error, the server has encountered an error while processing the request

HTTP狀態碼錶

100：繼續。客戶端應繼續其請求

101：切換協議。服務器根據客戶端的請求切換協議。只能切換到更高級的協議，例如，切換到HTTP的新版本協議

2開頭的狀態碼

200：請求成功。通常用於GET與POST請求

201：已建立。成功請求並建立了新的資源

202：已接受。已經接受請求，但未處理完成

203：非受權信息。請求成功。但返回的meta信息不在原始的服務器，而是一個副本

204：無內容。服務器成功處理，但未返回內容。在未更新網頁的狀況下，可確保瀏覽器繼續顯示當前文檔

205：重置內容。服務器處理成功，用戶終端（例如：瀏覽器）應重置文檔視圖。可經過此返回碼清除瀏覽器的表單域

206：部份內容。服務器成功處理了部分GET請求

3開頭的狀態碼

300：多種選擇。請求的資源可包括多個位置，相應可返回一個資源特徵與地址的列表用於用戶終端（例如：瀏覽器）選擇

301：永久移動。請求的資源已被永久的移動到新URI，返回信息會包括新的URI，瀏覽器會自動定向到新URI。從此任何新的請求都應使用新的URI代替

302：臨時移動。與301相似。但資源只是臨時被移動。客戶端應繼續使用原有URI

303：查看其它地址。與301相似。使用GET和POST請求查看

304：未修改。所請求的資源未修改，服務器返回此狀態碼時，不會返回任何資源。客戶端一般會緩存訪問過的資源，經過提供一個頭信息指出客戶端但願只返回在指定日期以後修改的資源

305：使用代理。所請求的資源必須經過代理訪問

306：已經被廢棄的HTTP狀態碼

307：臨時重定向。與302相似。使用GET請求重定向

4開頭的狀態碼

400：客戶端請求的語法錯誤，服務器沒法理解

401：請求要求用戶的身份認證

402：保留，未來使用

403：服務器理解請求客戶端的請求，可是拒絕執行此請求

404：服務器沒法根據客戶端的請求找到資源（網頁）。經過此代碼，網站設計人員可設置"您所請求的資源沒法找到"的個性頁面

405：客戶端請求中的方法被禁止

406：服務器沒法根據客戶端請求的內容特性完成請求

407：請求要求代理的身份認證，與401相似，但請求者應當使用代理進行受權

408：服務器等待客戶端發送的請求時間過長，超時

409：服務器完成客戶端的PUT請求是可能返回此代碼，服務器處理請求時發生了衝突

410：客戶端請求的資源已經不存在。410不一樣於404，若是資源之前有如今被永久刪除了可以使用410代碼，網站設計人員可經過301代碼指定資源的新位置

411：服務器沒法處理客戶端發送的不帶Content-Length的請求信息

412：客戶端請求信息的先決條件錯誤

413：因爲請求的實體過大，服務器沒法處理，所以拒絕請求。爲防止客戶端的連續請求，服務器可能會關閉鏈接。若是隻是服務器暫時沒法處理，則會包含一個Retry-After的響應信息

414：請求的URI過長（URI一般爲網址），服務器沒法處理

415：服務器沒法處理請求附帶的媒體格式

416：客戶端請求的範圍無效

417：服務器沒法知足Expect的請求頭信息

5開頭的狀態碼

500；服務器內部錯誤，沒法完成請求

501：服務器不支持請求的功能，沒法完成請求

502：充當網關或代理的服務器，從遠端服務器接收到了一個無效的請求

503：因爲超載或系統維護，服務器暫時的沒法處理客戶端的請求。延時的長度可包含在服務器的Retry-After頭信息中

504：充當網關或代理的服務器，未及時從遠端服務器獲取請求

505：務器不支持請求的HTTP協議的版本，沒法完成處理

506：由《透明內容協商協議》（RFC 2295）擴展，表明服務器存在內部配置錯誤：被請求的協商變元資源被配置爲在透明內容協商中使用本身，所以在一個協商處理中不是一個合適的重點。

507：服務器沒法存儲完成請求所必須的內容。這個情況被認爲是臨時的。WebDAV (RFC 4918)

509：服務器達到帶寬限制。這不是一個官方的狀態碼，可是仍被普遍使用。

510：獲取資源所須要的策略並無沒知足。（RFC 2774）

英文版

HTTP Status Code Table (Version 1)

100: continue. Clients should continue their request

101: Switch the protocol. The server switches the protocol according to the client's request. You can only switch to more advanced protocols, for example, to switch to the new version of HTTP

2 The beginning of the status code

200: The request was successful. Generally used for GET and POST requests

201: Created. Successfully requested and created new resource

202: Accepted. Already accepted the request but did not process it

203: unauthorized information. The request is successful. But the meta-information returned is not a copy of the original server, but a copy

204: No content. The server processed successfully but did not return content. Without updating the page, make sure that the browser continues to display the current document

205: Reset content. If the server is successfully processed, the user terminal (for example, browser) should reset the document view. This return code can be used to clear the browser's form fields

206: part of the content. The server successfully processed part of the GET request

3 at the beginning of the status code

300: a variety of options. The requested resource can include multiple locations, and a list of resource features and addresses can be returned accordingly for the user terminal (eg, browser) to select

301: move permanently. The requested resource has been permanently moved to the new URI, the returned information will include the new URI, and the browser will automatically redirect to the new URI. Any new requests in the future should use the new URI instead

302: temporary move. Similar to 301. But resources are only temporarily moved. The client should continue to use the original URI

303: View other addresses. Similar to 301. View using GET and POST requests

304: unmodified. The requested resource is unmodified, and the server does not return any resources when it returns this status code. Clients typically cache accessed resources by providing a header that states that the client wants to return only those resources that were modified after the specified date

305: Use a proxy. The requested resource must be accessed through a proxy

306: HTTP status code that has been discarded

307: temporary redirect. Similar to 302. Use GET request redirection

4 The beginning of the status code

400: Client request syntax error, the server can not understand

401: The request asks the user for authentication

402: Reserved for future use

403: The server understands the request for the client, but refuses to execute the request

404: The server could not find the resource (web page) based on the client's request. With this code, a website designer can set a personalized page that says "The resource you requested can not be found."

405: The method in the client request is disabled

406: The server can not complete the request based on the content characteristics requested by the client

407: The request asks for the identity of the proxy, similar to 401, but the requester should use the proxy for authorization

408: The server waits for the client to send the request for too long, timeout

409: The server may complete the client's PUT request is likely to return this code, the server encountered a request conflict

410: The client requested resource no longer exists. 410 is different from 404, if the resource has been permanently deleted for the 410 code, the site designer can specify the new location of the resource with the 301 code

411: The server was unable to process the request message sent by the client without Content-Length

412: Client request information is a prerequisite error

413: The request is denied because the requested entity is too large for the server to process. To prevent continuous client requests, the server may close the connection. If only the server temporarily unable to deal with, it will contain a Retry-After response

414: Request URI is too long (URI is usually the URL), the server can not handle

415: The server was unable to process the media format attached to the request

416: Invalid client request range

417: The server can not satisfy Expect's request header information

5 The beginning of the status code

500; internal server error, unable to complete the request

501: The server does not support the requested functionality and can not complete the request

502: A server acting as a gateway or proxy receives an invalid request from a remote server

503: The server is temporarily unable to process the client's request due to overloading or system maintenance. The length of the delay can be included in the server's Retry-After header

504: act as a gateway or proxy server, did not get requests from the remote server in time

505: The server does not support the requested version of the HTTP protocol and can not complete the process

506: Expanded by Transparent Content Negotiation Protocol (RFC 2295), representing an internal configuration error on behalf of the server: The requested Negotiation Argument resource is configured to use itself in transparent content negotiation and is therefore not suitable in a negotiation process Focus.

507: The server can not store the content necessary to complete the request. This situation is considered temporary. WebDAV (RFC 4918)

509: The server reached the bandwidth limit. This is not an official status code, but is still widely used.

510: The strategy needed to get the resource is not missing. (RFC 2774)