zzijzzij亚洲日本少妇jizjiz,99久久99久久免费精品蜜桃,www.成色av久久成人,18video性欧美19sex,久久综合九色综合欧美亚洲

為用戶創(chuàng)造價值的開發(fā)公司

始終追求工匠精神,是您靠譜的H5開發(fā)、小程序開發(fā)、微信開發(fā)供應商

藍暢首頁 >> 動態(tài)

Nginx常見錯誤及處理方法

時間:2019-09-11 02:18:26 | 來源:




404 bad request

一般原因:請求的Header過大
解決方法:配置nginx.conf相關設置
  1. client_header_buffer_size 16k;

  2. large_client_header_buffers 4 64k;

413 Request Entity Too Large
一般原因:一般出現(xiàn)在上傳文件
解決方法:配置nginx.conf相關設置
  1. client_max_body_size 10m;

  配置php.ini如下(必須和nginx.conf配置一致)
  1. post_max_size=10M

  2. upload_max_filesize=2M

499 Client Closed Request
一般原因:客戶端在為等到服務器相應返回前就關閉了客戶端描述符。一般出現(xiàn)在客戶端設置超時后,主動關閉socket.
解決方法:根據(jù)實際Nginx后端服務器的處理時間修改客戶端超時時間。
500 Internal Server Rrror
一般原因:腳本錯誤,(php語法錯誤、lua語法錯誤)
     訪問量過大,系統(tǒng)資源限制,不能打開過多文件
     磁盤空間不足。(access log開啟可能導致磁盤滿溢 關閉)
解決方法:語法錯誤查看nginx_err_log php_err_log。
     文件訪問量:
     1.修改nginx配置文件
  1. worker_rlimit_nofile 65535;

     2.修改/etc/security/limits.conf
  1. * soft nofile 65535

  2. * hard nofile 65535

502 Bad Gateway、503 Serveice Unavailable
一般原因:后端服務無法處理,業(yè)務中斷。
解決方法:從后端日志獲取錯誤原因,解決后端服務器問題。
504 Gateway Timeout
一般原因:后端服務器在超時時間內(nèi),未響應Nginx代理請求
解決方法:根據(jù)后端服務器實際處理情況,調(diào)正后端請求超時時間。
  1. proxy_read_timeout 90;

  2. proxy_send_timeout 90;

一般原因:可能網(wǎng)站頁面緩存大,而fastcgi默認進程響應緩存區(qū)8k
解決方法:配置nginx.conf相關設置
  1. fastcgi_buffers 8 128k

  1. send_timeout 60;

upstream jira_Cluster_web {    #ip_hash;server 10.143.50.15:8081 ;              server 10.143.50.16:8081 backup;      }server {        listen       80;        server_name   jira1.gomeholdings.com;    index index.html index.htm;    #root html;location / {        proxy_redirect off;        proxy_set_header Host $host;        proxy_set_header X-Real-IP $remote_addr;        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;        client_body_buffer_size 128k;        proxy_connect_timeout 90;        proxy_send_timeout 90;        proxy_read_timeout 90;        proxy_buffer_size 4k;        proxy_buffers 4 32k;        proxy_busy_buffers_size 64k;        proxy_temp_file_write_size 64k;        #proxy_set_header X-Forwarded-Host $host;#proxy_set_header X-Forwarded-Server $host;#proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;proxy_pass  http://jira_Cluster_web/;        #proxy_pass  http://10.143.50.15:8081;proxy_http_version 1.1;        proxy_set_header Connection "";        }}
View Code


######Nginx配置文件nginx.conf中文詳解######定義Nginx運行的用戶和用戶組user www www;#nginx進程數(shù),建議設置為等于CPU總核心數(shù)。worker_processes 8; #全局錯誤日志定義類型,[ debug | info | notice | warn | error | crit ]error_log /usr/local/nginx/logs/error.log info;#進程pid文件pid /usr/local/nginx/logs/nginx.pid;#指定進程可以打開的最大描述符:數(shù)目#工作模式與連接數(shù)上限#這個指令是指當一個nginx進程打開的最多文件描述符數(shù)目,理論值應該是最多打開文件數(shù)(ulimit -n)與nginx進程數(shù)相除,但是nginx分配請求并不是那么均勻,所以最好與ulimit -n 的值保持一致。#現(xiàn)在在linux 2.6內(nèi)核下開啟文件打開數(shù)為65535,worker_rlimit_nofile就相應應該填寫65535。#這是因為nginx調(diào)度時分配請求到進程并不是那么的均衡,所以假如填寫10240,總并發(fā)量達到3-4萬時就有進程可能超過10240了,這時會返回502錯誤。worker_rlimit_nofile 65535;events{    #參考事件模型,use [ kqueue | rtsig | epoll | /dev/poll | select | poll ]; epoll模型#是Linux 2.6以上版本內(nèi)核中的高性能網(wǎng)絡I/O模型,linux建議epoll,如果跑在FreeBSD上面,就用kqueue模型。#補充說明:#與apache相類,nginx針對不同的操作系統(tǒng),有不同的事件模型#A)標準事件模型#Select、poll屬于標準事件模型,如果當前系統(tǒng)不存在更有效的方法,nginx會選擇select或poll#B)高效事件模型#Kqueue:使用于FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 和 MacOS X.使用雙處理器的MacOS X系統(tǒng)使用kqueue可能會造成內(nèi)核崩潰。#Epoll:使用于Linux內(nèi)核2.6版本及以后的系統(tǒng)。#/dev/poll:使用于Solaris 7 11/99+,HP/UX 11.22+ (eventport),IRIX 6.5.15+ 和 Tru64 UNIX 5.1A+。#Eventport:使用于Solaris 10。 為了防止出現(xiàn)內(nèi)核崩潰的問題, 有必要安裝安全補丁。    use epoll;    #單個進程最大連接數(shù)(最大連接數(shù)=連接數(shù)*進程數(shù))#根據(jù)硬件調(diào)整,和前面工作進程配合起來用,盡量大,但是別把cpu跑到100%就行。每個進程允許的最多連接數(shù),理論上每臺nginx服務器的最大連接數(shù)為。worker_connections 65535;    #keepalive超時時間。keepalive_timeout 60;    #客戶端請求頭部的緩沖區(qū)大小。這個可以根據(jù)你的系統(tǒng)分頁大小來設置,一般一個請求頭的大小不會超過1k,不過由于一般系統(tǒng)分頁都要大于1k,所以這里設置為分頁大小。#分頁大小可以用命令getconf PAGESIZE 取得。#[root@web001 ~]# getconf PAGESIZE#4096#但也有client_header_buffer_size超過4k的情況,但是client_header_buffer_size該值必須設置為“系統(tǒng)分頁大小”的整倍數(shù)。    client_header_buffer_size 4k;    #這個將為打開文件指定緩存,默認是沒有啟用的,max指定緩存數(shù)量,建議和打開文件數(shù)一致,inactive是指經(jīng)過多長時間文件沒被請求后刪除緩存。open_file_cache max=65535 inactive=60s;    #這個是指多長時間檢查一次緩存的有效信息。#語法:open_file_cache_valid time 默認值:open_file_cache_valid 60 使用字段:http, server, location 這個指令指定了何時需要檢查open_file_cache中緩存項目的有效信息.    open_file_cache_valid 80s;    #open_file_cache指令中的inactive參數(shù)時間內(nèi)文件的最少使用次數(shù),如果超過這個數(shù)字,文件描述符一直是在緩存中打開的,如上例,如果有一個文件在inactive時間內(nèi)一次沒被使用,它將被移除。#語法:open_file_cache_min_uses number 默認值:open_file_cache_min_uses 1 使用字段:http, server, location  這個指令指定了在open_file_cache指令無效的參數(shù)中一定的時間范圍內(nèi)可以使用的最小文件數(shù),如果使用更大的值,文件描述符在cache中總是打開狀態(tài).open_file_cache_min_uses 1;        #語法:open_file_cache_errors on | off 默認值:open_file_cache_errors off 使用字段:http, server, location 這個指令指定是否在搜索一個文件是記錄cache錯誤.    open_file_cache_errors on;}   #設定http服務器,利用它的反向代理功能提供負載均衡支持http{    #文件擴展名與文件類型映射表    include mime.types;    #默認文件類型default_type application/octet-stream;    #默認編碼#charset utf-8;#服務器名字的hash表大小#保存服務器名字的hash表是由指令server_names_hash_max_size 和server_names_hash_bucket_size所控制的。參數(shù)hash bucket size總是等于hash表的大小,并且是一路處理器緩存大小的倍數(shù)。在減少了在內(nèi)存中的存取次數(shù)后,使在處理器中加速查找hash表鍵值成為可能。如果hash bucket size等于一路處理器緩存的大小,那么在查找鍵的時候,最壞的情況下在內(nèi)存中查找的次數(shù)為2。第一次是確定存儲單元的地址,第二次是在存儲單元中查找鍵 值。因此,如果Nginx給出需要增大hash max size 或 hash bucket size的提示,那么首要的是增大前一個參數(shù)的大小.server_names_hash_bucket_size 128;    #客戶端請求頭部的緩沖區(qū)大小。這個可以根據(jù)你的系統(tǒng)分頁大小來設置,一般一個請求的頭部大小不會超過1k,不過由于一般系統(tǒng)分頁都要大于1k,所以這里設置為分頁大小。分頁大小可以用命令getconf PAGESIZE取得。    client_header_buffer_size 32k;    #客戶請求頭緩沖大小。nginx默認會用client_header_buffer_size這個buffer來讀取header值,如果header過大,它會使用large_client_header_buffers來讀取。large_client_header_buffers 4 64k;    #設定通過nginx上傳文件的大小    client_max_body_size 8m;    #開啟高效文件傳輸模式,sendfile指令指定nginx是否調(diào)用sendfile函數(shù)來輸出文件,對于普通應用設為 on,如果用來進行下載等應用磁盤IO重負載應用,可設置為off,以平衡磁盤與網(wǎng)絡I/O處理速度,降低系統(tǒng)的負載。注意:如果圖片顯示不正常把這個改成off。#sendfile指令指定 nginx 是否調(diào)用sendfile 函數(shù)(zero copy 方式)來輸出文件,對于普通應用,必須設為on。如果用來進行下載等應用磁盤IO重負載應用,可設置為off,以平衡磁盤與網(wǎng)絡IO處理速度,降低系統(tǒng)uptime。    sendfile on;    #開啟目錄列表訪問,合適下載服務器,默認關閉。    autoindex on;    #此選項允許或禁止使用socke的TCP_CORK的選項,此選項僅在使用sendfile的時候使用    tcp_nopush on;         tcp_nodelay on;    #長連接超時時間,單位是秒keepalive_timeout 120;    #FastCGI相關參數(shù)是為了改善網(wǎng)站的性能:減少資源占用,提高訪問速度。下面參數(shù)看字面意思都能理解。fastcgi_connect_timeout 300;    fastcgi_send_timeout 300;    fastcgi_read_timeout 300;    fastcgi_buffer_size 64k;    fastcgi_buffers 4 64k;    fastcgi_busy_buffers_size 128k;    fastcgi_temp_file_write_size 128k;    #gzip模塊設置gzip on; #開啟gzip壓縮輸出gzip_min_length 1k;    #最小壓縮文件大小gzip_buffers 4 16k;    #壓縮緩沖區(qū)gzip_http_version 1.0;    #壓縮版本(默認1.1,前端如果是squid2.5請使用1.0)gzip_comp_level 2;    #壓縮等級gzip_types text/plain application/x-javascript text/css application/xml;    #壓縮類型,默認就已經(jīng)包含textml,所以下面就不用再寫了,寫上去也不會有問題,但是會有一個warn。    gzip_vary on;    #開啟限制IP連接數(shù)的時候需要使用#limit_zone crawler $binary_remote_addr 10m;#負載均衡配置    upstream piao.jd.com {             #upstream的負載均衡,weight是權重,可以根據(jù)機器配置定義權重。weigth參數(shù)表示權值,權值越高被分配到的幾率越大。server 192.168.80.121:80 weight=3;        server 192.168.80.122:80 weight=2;        server 192.168.80.123:80 weight=3;        #nginx的upstream目前支持4種方式的分配#1、輪詢(默認)#每個請求按時間順序逐一分配到不同的后端服務器,如果后端服務器down掉,能自動剔除。#2、weight#指定輪詢幾率,weight和訪問比率成正比,用于后端服務器性能不均的情況。#例如:#upstream bakend {#    server 192.168.0.14 weight=10;#    server 192.168.0.15 weight=10;#}#2、ip_hash#每個請求按訪問ip的hash結果分配,這樣每個訪客固定訪問一個后端服務器,可以解決session的問題。#例如:#upstream bakend {#    ip_hash;#    server 192.168.0.14:88;#    server 192.168.0.15:80;#}#3、fair(第三方)#按后端服務器的響應時間來分配請求,響應時間短的優(yōu)先分配。#upstream backend {#    server server1;#    server server2;#    fair;#}#4、url_hash(第三方)#按訪問url的hash結果來分配請求,使每個url定向到同一個后端服務器,后端服務器為緩存時比較有效。#例:在upstream中加入hash語句,server語句中不能寫入weight等其他的參數(shù),hash_method是使用的hash算法#upstream backend {#    server squid1:3128;#    server squid2:3128;#    hash $request_uri;#    hash_method crc32;#}#tips:#upstream bakend{#定義負載均衡設備的Ip及設備狀態(tài)}{#    ip_hash;#    server 127.0.0.1:9090 down;#    server 127.0.0.1:8080 weight=2;#    server 127.0.0.1:6060;#    server 127.0.0.1:7070 backup;#}#在需要使用負載均衡的server中增加 proxy_pass http://bakend/;#每個設備的狀態(tài)設置為:#1.down表示單前的server暫時不參與負載#2.weight為weight越大,負載的權重就越大。#3.max_fails:允許請求失敗的次數(shù)默認為1.當超過最大次數(shù)時,返回proxy_next_upstream模塊定義的錯誤#4.fail_timeout:max_fails次失敗后,暫停的時間。#5.backup: 其它所有的非backup機器down或者忙的時候,請求backup機器。所以這臺機器壓力會最輕。#nginx支持同時設置多組的負載均衡,用來給不用的server來使用。#client_body_in_file_only設置為On 可以講client post過來的數(shù)據(jù)記錄到文件中用來做debug#client_body_temp_path設置記錄文件的目錄 可以設置最多3層目錄#location對URL進行匹配.可以進行重定向或者進行新的代理 負載均衡    }                   #虛擬主機的配置    server    {        #監(jiān)聽端口listen 80;        #域名可以有多個,用空格隔開        server_name www.jd.com jd.com;        index index.html index.htm index.php;        root /data/www/jd;        #對******進行負載均衡location ~ .*.(php|php5)?$        {            fastcgi_pass 127.0.0.1:9000;            fastcgi_index index.php;            include fastcgi.conf;        }                 #圖片緩存時間設置location ~ .*.(gif|jpg|jpeg|png|bmp|swf)$        {            expires 10d;        }                 #JS和CSS緩存時間設置location ~ .*.(js|css)?$        {            expires 1h;        }                 #日志格式設定#$remote_addr與$http_x_forwarded_for用以記錄客戶端的ip地址;#$remote_user:用來記錄客戶端用戶名稱;#$time_local: 用來記錄訪問時間與時區(qū);#$request: 用來記錄請求的url與http協(xié)議;#$status: 用來記錄請求狀態(tài);成功是200,#$body_bytes_sent :記錄發(fā)送給客戶端文件主體內(nèi)容大小;#$http_referer:用來記錄從那個頁面鏈接訪問過來的;#$http_user_agent:記錄客戶瀏覽器的相關信息;#通常web服務器放在反向代理的后面,這樣就不能獲取到客戶的IP地址了,通過$remote_add拿到的IP地址是反向代理服務器的iP地址。反向代理服務器在轉發(fā)請求的http頭信息中,可以增加x_forwarded_for信息,用以記錄原有客戶端的IP地址和原來客戶端的請求的服務器地址。log_format access '$remote_addr - $remote_user [$time_local] "$request" ''$status $body_bytes_sent "$http_referer" ''"$http_user_agent" $http_x_forwarded_for';                 #定義本虛擬主機的訪問日志access_log  /usr/local/nginx/logs/host.access.log  main;        access_log  /usr/local/nginx/logs/host.access.404.log  log404;                 #對 "/" 啟用反向代理location / {            proxy_pass http://127.0.0.1:88;            proxy_redirect off;            proxy_set_header X-Real-IP $remote_addr;                         #后端的Web服務器可以通過X-Forwarded-For獲取用戶真實IPproxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;                         #以下是一些反向代理的配置,可選。            proxy_set_header Host $host;            #允許客戶端請求的最大單文件字節(jié)數(shù)            client_max_body_size 10m;            #緩沖區(qū)代理緩沖用戶端請求的最大字節(jié)數(shù),#如果把它設置為比較大的數(shù)值,例如256k,那么,無論使用firefox還是IE瀏覽器,來提交任意小于256k的圖片,都很正常。如果注釋該指令,使用默認的client_body_buffer_size設置,也就是操作系統(tǒng)頁面大小的兩倍,8k或者16k,問題就出現(xiàn)了。#無論使用firefox4.0還是IE8.0,提交一個比較大,200k左右的圖片,都返回500 Internal Server Error錯誤            client_body_buffer_size 128k;            #表示使nginx阻止HTTP應答代碼為400或者更高的應答。            proxy_intercept_errors on;            #后端服務器連接的超時時間_發(fā)起握手等候響應超時時間#nginx跟后端服務器連接超時時間(代理連接超時)proxy_connect_timeout 90;            #后端服務器數(shù)據(jù)回傳時間(代理發(fā)送超時)#后端服務器數(shù)據(jù)回傳時間_就是在規(guī)定時間之內(nèi)后端服務器必須傳完所有的數(shù)據(jù)proxy_send_timeout 90;            #連接成功后,后端服務器響應時間(代理接收超時)#連接成功后_等候后端服務器響應時間_其實已經(jīng)進入后端的排隊之中等候處理(也可以說是后端服務器處理請求的時間)proxy_read_timeout 90;            #設置代理服務器(nginx)保存用戶頭信息的緩沖區(qū)大小#設置從被代理服務器讀取的第一部分應答的緩沖區(qū)大小,通常情況下這部分應答中包含一個小的應答頭,默認情況下這個值的大小為指令proxy_buffers中指定的一個緩沖區(qū)的大小,不過可以將其設置為更小            proxy_buffer_size 4k;            #proxy_buffers緩沖區(qū),網(wǎng)頁平均在32k以下的設置#設置用于讀取應答(來自被代理服務器)的緩沖區(qū)數(shù)目和大小,默認情況也為分頁大小,根據(jù)操作系統(tǒng)的不同可能是4k或者8kproxy_buffers 4 32k;            #高負荷下緩沖大?。╬roxy_buffers*2)            proxy_busy_buffers_size 64k;            #設置在寫入proxy_temp_path時數(shù)據(jù)的大小,預防一個工作進程在傳遞文件時阻塞太長#設定緩存文件夾大小,大于這個值,將從upstream服務器傳            proxy_temp_file_write_size 64k;        }                          #設定查看Nginx狀態(tài)的地址location /NginxStatus {            stub_status on;            access_log on;            auth_basic "NginxStatus";            auth_basic_user_file confpasswd;            #htpasswd文件的內(nèi)容可以用apache提供的htpasswd工具來產(chǎn)生。        }                 #本地動靜分離反向代理配置#所有jsp的頁面均交由tomcat或resin處理location ~ .(jsp|jspx|do)?$ {            proxy_set_header Host $host;            proxy_set_header X-Real-IP $remote_addr;            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;            proxy_pass http://127.0.0.1:8080;        }                 #所有靜態(tài)文件由nginx直接讀取不經(jīng)過tomcat或resinlocation ~ .*.(htm|html|gif|jpg|jpeg|png|bmp|swf|ioc|rar|zip|txt|flv|mid|doc|ppt|        pdf|xls|mp3|wma)$        {            expires 15d;         }                 location ~ .*.(js|css)?$        {            expires 1h;        }    }}######Nginx配置文件nginx.conf中文詳解#####
View Code



中文配置詳解:

http://tool.oschina.net/apidocs/apidoc?api=nginx-zh

http://shouce.jb51.net/nginx/left.html

官方文檔:

http://nginx.org/en/docs/http/ngx_http_core_module.html


附表:HTTP響應碼
1XX代表提示信息,2XX代表成功信息,3XX代表重定向信息,4XX代表客戶端錯誤信息,5XX代表服務器錯誤信息
狀態(tài)碼含義
100客戶端應當繼續(xù)發(fā)送請求。這個臨時響應是用來通知客戶端它的部分請求已經(jīng)被服務器接收,且仍未被拒絕。客戶端應當繼續(xù)發(fā)送請求的剩余部分,或者如果請求已經(jīng)完成,忽略這個響應。服務器必須在請求完成后向客戶端發(fā)送一個最終響應。
101服務器已經(jīng)理解了客戶端的請求,并將通過Upgrade 消息頭通知客戶端采用不同的協(xié)議來完成這個請求。在發(fā)送完這個響應最后的空行后,服務器將會切換到在Upgrade 消息頭中定義的那些協(xié)議。   只有在切換新的協(xié)議更有好處的時候才應該采取類似措施。例如,切換到新的HTTP 版本比舊版本更有優(yōu)勢,或者切換到一個實時且同步的協(xié)議以傳送利用此類特性的資源。
102由WebDAV(RFC 2518)擴展的狀態(tài)碼,代表處理將被繼續(xù)執(zhí)行。
200請求已成功,請求所希望的響應頭或數(shù)據(jù)體將隨此響應返回。
201請求已經(jīng)被實現(xiàn),而且有一個新的資源已經(jīng)依據(jù)請求的需要而建立,且其 URI 已經(jīng)隨Location 頭信息返回。假如需要的資源無法及時建立的話,應當返回 '202 Accepted'。
202服務器已接受請求,但尚未處理。正如它可能被拒絕一樣,最終該請求可能會也可能不會被執(zhí)行。在異步操作的場合下,沒有比發(fā)送這個狀態(tài)碼更方便的做法了。   返回202狀態(tài)碼的響應的目的是允許服務器接受其他過程的請求(例如某個每天只執(zhí)行一次的基于批處理的操作),而不必讓客戶端一直保持與服務器的連接直到批處理操作全部完成。在接受請求處理并返回202狀態(tài)碼的響應應當在返回的實體中包含一些指示處理當前狀態(tài)的信息,以及指向處理狀態(tài)監(jiān)視器或狀態(tài)預測的指針,以便用戶能夠估計操作是否已經(jīng)完成。
203服務器已成功處理了請求,但返回的實體頭部元信息不是在原始服務器上有效的確定集合,而是來自本地或者第三方的拷貝。當前的信息可能是原始版本的子集或者超集。例如,包含資源的元數(shù)據(jù)可能導致原始服務器知道元信息的超級。使用此狀態(tài)碼不是必須的,而且只有在響應不使用此狀態(tài)碼便會返回200 OK的情況下才是合適的。
204服務器成功處理了請求,但不需要返回任何實體內(nèi)容,并且希望返回更新了的元信息。響應可能通過實體頭部的形式,返回新的或更新后的元信息。如果存在這些頭部信息,則應當與所請求的變量相呼應。   如果客戶端是瀏覽器的話,那么用戶瀏覽器應保留發(fā)送了該請求的頁面,而不產(chǎn)生任何文檔視圖上的變化,即使按照規(guī)范新的或更新后的元信息應當被應用到用戶瀏覽器活動視圖中的文檔。   由于204響應被禁止包含任何消息體,因此它始終以消息頭后的第一個空行結尾。
205服務器成功處理了請求,且沒有返回任何內(nèi)容。但是與204響應不同,返回此狀態(tài)碼的響應要求請求者重置文檔視圖。該響應主要是被用于接受用戶輸入后,立即重置表單,以便用戶能夠輕松地開始另一次輸入。   與204響應一樣,該響應也被禁止包含任何消息體,且以消息頭后的第一個空行結束。
206服務器已經(jīng)成功處理了部分 GET 請求。類似于 FlashGet 或者迅雷這類的 HTTP 下載工具都是使用此類響應實現(xiàn)斷點續(xù)傳或者將一個大文檔分解為多個下載段同時下載。   該請求必須包含 Range 頭信息來指示客戶端希望得到的內(nèi)容范圍,并且可能包含 If-Range 來作為請求條件。   響應必須包含如下的頭部域:   Content-Range 用以指示本次響應中返回的內(nèi)容的范圍;如果是 Content-Type 為 multipart/byteranges 的多段下載,則每一 multipart 段中都應包含 Content-Range 域用以指示本段的內(nèi)容范圍。假如響應中包含 Content-Length,那么它的數(shù)值必須匹配它返回的內(nèi)容范圍的真實字節(jié)數(shù)。   Date   ETag 和/或 Content-Location,假如同樣的請求本應該返回200響應。   Expires, Cache-Control,和/或 Vary,假如其值可能與之前相同變量的其他響應對應的值不同的話。   假如本響應請求使用了 If-Range 強緩存驗證,那么本次響應不應該包含其他實體頭;假如本響應的請求使用了 If-Range 弱緩存驗證,那么本次響應禁止包含其他實體頭;這避免了緩存的實體內(nèi)容和更新了的實體頭信息之間的不一致。否則,本響應就應當包含所有本應該返回200響應中應當返回的所有實體頭部域。   假如 ETag 或 Last-Modified 頭部不能精確匹配的話,則客戶端緩存應禁止將206響應返回的內(nèi)容與之前任何緩存過的內(nèi)容組合在一起。   任何不支持 Range 以及 Content-Range 頭的緩存都禁止緩存206響應返回的內(nèi)容。
207由WebDAV(RFC 2518)擴展的狀態(tài)碼,代表之后的消息體將是一個XML消息,并且可能依照之前子請求數(shù)量的不同,包含一系列獨立的響應代碼。
300被請求的資源有一系列可供選擇的回饋信息,每個都有自己特定的地址和瀏覽器驅(qū)動的商議信息。用戶或瀏覽器能夠自行選擇一個首選的地址進行重定向。   除非這是一個 HEAD 請求,否則該響應應當包括一個資源特性及地址的列表的實體,以便用戶或瀏覽器從中選擇最合適的重定向地址。這個實體的格式由 Content-Type 定義的格式所決定。瀏覽器可能根據(jù)響應的格式以及瀏覽器自身能力,自動作出最合適的選擇。當然,RFC 2616規(guī)范并沒有規(guī)定這樣的自動選擇該如何進行。   如果服務器本身已經(jīng)有了首選的回饋選擇,那么在 Location 中應當指明這個回饋的 URI;瀏覽器可能會將這個 Location 值作為自動重定向的地址。此外,除非額外指定,否則這個響應也是可緩存的。
301被請求的資源已永久移動到新位置,并且將來任何對此資源的引用都應該使用本響應返回的若干個 URI 之一。如果可能,擁有鏈接編輯功能的客戶端應當自動把請求的地址修改為從服務器反饋回來的地址。除非額外指定,否則這個響應也是可緩存的。   新的永久性的 URI 應當在響應的 Location 域中返回。除非這是一個 HEAD 請求,否則響應的實體中應當包含指向新的 URI 的超鏈接及簡短說明。   如果這不是一個 GET 或者 HEAD 請求,因此瀏覽器禁止自動進行重定向,除非得到用戶的確認,因為請求的條件可能因此發(fā)生變化。   注意:對于某些使用 HTTP/1.0 協(xié)議的瀏覽器,當它們發(fā)送的 POST 請求得到了一個301響應的話,接下來的重定向請求將會變成 GET 方式。
302請求的資源現(xiàn)在臨時從不同的 URI 響應請求。由于這樣的重定向是臨時的,客戶端應當繼續(xù)向原有地址發(fā)送以后的請求。只有在Cache-Control或Expires中進行了指定的情況下,這個響應才是可緩存的。   新的臨時性的 URI 應當在響應的 Location 域中返回。除非這是一個 HEAD 請求,否則響應的實體中應當包含指向新的 URI  的超鏈接及簡短說明。   如果這不是一個 GET 或者 HEAD 請求,那么瀏覽器禁止自動進行重定向,除非得到用戶的確認,因為請求的條件可能因此發(fā)生變化。   注意:雖然RFC 1945和RFC 2068規(guī)范不允許客戶端在重定向時改變請求的方法,但是很多現(xiàn)存的瀏覽器將302響應視作為303響應,并且使用 GET 方式訪問在 Location 中規(guī)定的 URI,而無視原先請求的方法。狀態(tài)碼303和307被添加了進來,用以明確服務器期待客戶端進行何種反應。
303對應當前請求的響應可以在另一個 URI 上被找到,而且客戶端應當采用 GET 的方式訪問那個資源。這個方法的存在主要是為了允許由腳本激活的POST請求輸出重定向到一個新的資源。這個新的 URI 不是原始資源的替代引用。同時,303響應禁止被緩存。當然,第二個請求(重定向)可能被緩存。   新的 URI 應當在響應的 Location 域中返回。除非這是一個 HEAD 請求,否則響應的實體中應當包含指向新的 URI 的超鏈接及簡短說明。   注意:許多 HTTP/1.1 版以前的 瀏覽器不能正確理解303狀態(tài)。如果需要考慮與這些瀏覽器之間的互動,302狀態(tài)碼應該可以勝任,因為大多數(shù)的瀏覽器處理302響應時的方式恰恰就是上述規(guī)范要求客戶端處理303響應時應當做的。
304如果客戶端發(fā)送了一個帶條件的 GET 請求且該請求已被允許,而文檔的內(nèi)容(自上次訪問以來或者根據(jù)請求的條件)并沒有改變,則服務器應當返回這個狀態(tài)碼。304響應禁止包含消息體,因此始終以消息頭后的第一個空行結尾。   該響應必須包含以下的頭信息:   Date,除非這個服務器沒有時鐘。假如沒有時鐘的服務器也遵守這些規(guī)則,那么代理服務器以及客戶端可以自行將 Date 字段添加到接收到的響應頭中去(正如RFC 2068中規(guī)定的一樣),緩存機制將會正常工作。   ETag 和/或 Content-Location,假如同樣的請求本應返回200響應。   Expires, Cache-Control,和/或Vary,假如其值可能與之前相同變量的其他響應對應的值不同的話。   假如本響應請求使用了強緩存驗證,那么本次響應不應該包含其他實體頭;否則(例如,某個帶條件的 GET 請求使用了弱緩存驗證),本次響應禁止包含其他實體頭;這避免了緩存了的實體內(nèi)容和更新了的實體頭信息之間的不一致。   假如某個304響應指明了當前某個實體沒有緩存,那么緩存系統(tǒng)必須忽視這個響應,并且重復發(fā)送不包含限制條件的請求。   假如接收到一個要求更新某個緩存條目的304響應,那么緩存系統(tǒng)必須更新整個條目以反映所有在響應中被更新的字段的值。
305被請求的資源必須通過指定的代理才能被訪問。Location 域中將給出指定的代理所在的 URI 信息,接收者需要重復發(fā)送一個單獨的請求,通過這個代理才能訪問相應資源。只有原始服務器才能建立305響應。   注意:RFC 2068中沒有明確305響應是為了重定向一個單獨的請求,而且只能被原始服務器建立。忽視這些限制可能導致嚴重的安全后果。
306在最新版的規(guī)范中,306狀態(tài)碼已經(jīng)不再被使用。
307請求的資源現(xiàn)在臨時從不同的URI 響應請求。由于這樣的重定向是臨時的,客戶端應當繼續(xù)向原有地址發(fā)送以后的請求。只有在Cache-Control或Expires中進行了指定的情況下,這個響應才是可緩存的。   新的臨時性的URI 應當在響應的 Location 域中返回。除非這是一個HEAD 請求,否則響應的實體中應當包含指向新的URI 的超鏈接及簡短說明。因為部分瀏覽器不能識別307響應,因此需要添加上述必要信息以便用戶能夠理解并向新的 URI 發(fā)出訪問請求。   如果這不是一個GET 或者 HEAD 請求,那么瀏覽器禁止自動進行重定向,除非得到用戶的確認,因為請求的條件可能因此發(fā)生變化。
4001、語義有誤,當前請求無法被服務器理解。除非進行修改,否則客戶端不應該重復提交這個請求。   2、請求參數(shù)有誤。
401當前請求需要用戶驗證。該響應必須包含一個適用于被請求資源的 WWW-Authenticate 信息頭用以詢問用戶信息??蛻舳丝梢灾貜吞峤灰粋€包含恰當?shù)?Authorization 頭信息的請求。如果當前請求已經(jīng)包含了 Authorization 證書,那么401響應代表著服務器驗證已經(jīng)拒絕了那些證書。如果401響應包含了與前一個響應相同的身份驗證詢問,且瀏覽器已經(jīng)至少嘗試了一次驗證,那么瀏覽器應當向用戶展示響應中包含的實體信息,因為這個實體信息中可能包含了相關診斷信息。參見RFC 2617。
402該狀態(tài)碼是為了將來可能的需求而預留的。
403服務器已經(jīng)理解請求,但是拒絕執(zhí)行它。與401響應不同的是,身份驗證并不能提供任何幫助,而且這個請求也不應該被重復提交。如果這不是一個 HEAD 請求,而且服務器希望能夠講清楚為何請求不能被執(zhí)行,那么就應該在實體內(nèi)描述拒絕的原因。當然服務器也可以返回一個404響應,假如它不希望讓客戶端獲得任何信息。
404請求失敗,請求所希望得到的資源未被在服務器上發(fā)現(xiàn)。沒有信息能夠告訴用戶這個狀況到底是暫時的還是永久的。假如服務器知道情況的話,應當使用410狀態(tài)碼來告知舊資源因為某些內(nèi)部的配置機制問題,已經(jīng)永久的不可用,而且沒有任何可以跳轉的地址。404這個狀態(tài)碼被廣泛應用于當服務器不想揭示到底為何請求被拒絕或者沒有其他適合的響應可用的情況下。
405請求行中指定的請求方法不能被用于請求相應的資源。該響應必須返回一個Allow 頭信息用以表示出當前資源能夠接受的請求方法的列表。   鑒于 PUT,DELETE 方法會對服務器上的資源進行寫操作,因而絕大部分的網(wǎng)頁服務器都不支持或者在默認配置下不允許上述請求方法,對于此類請求均會返回405錯誤。
406請求的資源的內(nèi)容特性無法滿足請求頭中的條件,因而無法生成響應實體。   除非這是一個 HEAD 請求,否則該響應就應當返回一個包含可以讓用戶或者瀏覽器從中選擇最合適的實體特性以及地址列表的實體。實體的格式由 Content-Type 頭中定義的媒體類型決定。瀏覽器可以根據(jù)格式及自身能力自行作出最佳選擇。但是,規(guī)范中并沒有定義任何作出此類自動選擇的標準。
407與401響應類似,只不過客戶端必須在代理服務器上進行身份驗證。代理服務器必須返回一個 Proxy-Authenticate 用以進行身份詢問??蛻舳丝梢苑祷匾粋€ Proxy-Authorization 信息頭用以驗證。參見RFC 2617。
408請求超時。客戶端沒有在服務器預備等待的時間內(nèi)完成一個請求的發(fā)送??蛻舳丝梢噪S時再次提交這一請求而無需進行任何更改。
409由于和被請求的資源的當前狀態(tài)之間存在沖突,請求無法完成。這個代碼只允許用在這樣的情況下才能被使用:用戶被認為能夠解決沖突,并且會重新提交新的請求。該響應應當包含足夠的信息以便用戶發(fā)現(xiàn)沖突的源頭。   沖突通常發(fā)生于對 PUT 請求的處理中。例如,在采用版本檢查的環(huán)境下,某次 PUT 提交的對特定資源的修改請求所附帶的版本信息與之前的某個(第三方)請求向沖突,那么此時服務器就應該返回一個409錯誤,告知用戶請求無法完成。此時,響應實體中很可能會包含兩個沖突版本之間的差異比較,以便用戶重新提交歸并以后的新版本。
410被請求的資源在服務器上已經(jīng)不再可用,而且沒有任何已知的轉發(fā)地址。這樣的狀況應當被認為是永久性的。如果可能,擁有鏈接編輯功能的客戶端應當在獲得用戶許可后刪除所有指向這個地址的引用。如果服務器不知道或者無法確定這個狀況是否是永久的,那么就應該使用404狀態(tài)碼。除非額外說明,否則這個響應是可緩存的。   410響應的目的主要是幫助網(wǎng)站管理員維護網(wǎng)站,通知用戶該資源已經(jīng)不再可用,并且服務器擁有者希望所有指向這個資源的遠端連接也被刪除。這類事件在限時、增值服務中很普遍。同樣,410響應也被用于通知客戶端在當前服務器站點上,原本屬于某個個人的資源已經(jīng)不再可用。當然,是否需要把所有永久不可用的資源標記為'410 Gone',以及是否需要保持此標記多長時間,完全取決于服務器擁有者。
411服務器拒絕在沒有定義 Content-Length 頭的情況下接受請求。在添加了表明請求消息體長度的有效 Content-Length 頭之后,客戶端可以再次提交該請求。
412服務器在驗證在請求的頭字段中給出先決條件時,沒能滿足其中的一個或多個。這個狀態(tài)碼允許客戶端在獲取資源時在請求的元信息(請求頭字段數(shù)據(jù))中設置先決條件,以此避免該請求方法被應用到其希望的內(nèi)容以外的資源上。
413服務器拒絕處理當前請求,因為該請求提交的實體數(shù)據(jù)大小超過了服務器愿意或者能夠處理的范圍。此種情況下,服務器可以關閉連接以免客戶端繼續(xù)發(fā)送此請求。   如果這個狀況是臨時的,服務器應當返回一個 Retry-After 的響應頭,以告知客戶端可以在多少時間以后重新嘗試。
414請求的URI 長度超過了服務器能夠解釋的長度,因此服務器拒絕對該請求提供服務。這比較少見,通常的情況包括:   本應使用POST方法的表單提交變成了GET方法,導致查詢字符串(Query String)過長。   重定向URI “黑洞”,例如每次重定向把舊的 URI 作為新的 URI 的一部分,導致在若干次重定向后 URI 超長。   客戶端正在嘗試利用某些服務器中存在的安全漏洞攻擊服務器。這類服務器使用固定長度的緩沖讀取或操作請求的 URI,當 GET 后的參數(shù)超過某個數(shù)值后,可能會產(chǎn)生緩沖區(qū)溢出,導致任意代碼被執(zhí)行[1]。沒有此類漏洞的服務器,應當返回414狀態(tài)碼。
415對于當前請求的方法和所請求的資源,請求中提交的實體并不是服務器中所支持的格式,因此請求被拒絕。
416如果請求中包含了 Range 請求頭,并且 Range 中指定的任何數(shù)據(jù)范圍都與當前資源的可用范圍不重合,同時請求中又沒有定義 If-Range 請求頭,那么服務器就應當返回416狀態(tài)碼。   假如 Range 使用的是字節(jié)范圍,那么這種情況就是指請求指定的所有數(shù)據(jù)范圍的首字節(jié)位置都超過了當前資源的長度。服務器也應當在返回416狀態(tài)碼的同時,包含一個 Content-Range 實體頭,用以指明當前資源的長度。這個響應也被禁止使用 multipart/byteranges 作為其 Content-Type。
417在請求頭 Expect 中指定的預期內(nèi)容無法被服務器滿足,或者這個服務器是一個代理服務器,它有明顯的證據(jù)證明在當前路由的下一個節(jié)點上,Expect 的內(nèi)容無法被滿足。
421從當前客戶端所在的IP地址到服務器的連接數(shù)超過了服務器許可的最大范圍。通常,這里的IP地址指的是從服務器上看到的客戶端地址(比如用戶的網(wǎng)關或者代理服務器地址)。在這種情況下,連接數(shù)的計算可能涉及到不止一個終端用戶。
422從當前客戶端所在的IP地址到服務器的連接數(shù)超過了服務器許可的最大范圍。通常,這里的IP地址指的是從服務器上看到的客戶端地址(比如用戶的網(wǎng)關或者代理服務器地址)。在這種情況下,連接數(shù)的計算可能涉及到不止一個終端用戶。
422請求格式正確,但是由于含有語義錯誤,無法響應。(RFC 4918 WebDAV)423 Locked   當前資源被鎖定。(RFC 4918 WebDAV)
424由于之前的某個請求發(fā)生的錯誤,導致當前請求失敗,例如 PROPPATCH。(RFC 4918 WebDAV)
425在WebDav Advanced Collections 草案中定義,但是未出現(xiàn)在《WebDAV 順序集協(xié)議》(RFC 3658)中。
426客戶端應當切換到TLS/1.0。(RFC 2817)
449由微軟擴展,代表請求應當在執(zhí)行完適當?shù)牟僮骱筮M行重試。
500服務器遇到了一個未曾預料的狀況,導致了它無法完成對請求的處理。一般來說,這個問題都會在服務器的程序碼出錯時出現(xiàn)。
501服務器不支持當前請求所需要的某個功能。當服務器無法識別請求的方法,并且無法支持其對任何資源的請求。
502作為網(wǎng)關或者代理工作的服務器嘗試執(zhí)行請求時,從上游服務器接收到無效的響應。
503由于臨時的服務器維護或者過載,服務器當前無法處理請求。這個狀況是臨時的,并且將在一段時間以后恢復。如果能夠預計延遲時間,那么響應中可以包含一個 Retry-After 頭用以標明這個延遲時間。如果沒有給出這個 Retry-After 信息,那么客戶端應當以處理500響應的方式處理它。   注意:503狀態(tài)碼的存在并不意味著服務器在過載的時候必須使用它。某些服務器只不過是希望拒絕客戶端的連接。
504作為網(wǎng)關或者代理工作的服務器嘗試執(zhí)行請求時,未能及時從上游服務器(URI標識出的服務器,例如HTTP、FTP、LDAP)或者輔助服務器(例如DNS)收到響應。   注意:某些代理服務器在DNS查詢超時時會返回400或者500錯誤
505服務器不支持,或者拒絕支持在請求中使用的 HTTP 版本。這暗示著服務器不能或不愿使用與客戶端相同的版本。響應中應當包含一個描述了為何版本不被支持以及服務器支持哪些協(xié)議的實體。
506由《透明內(nèi)容協(xié)商協(xié)議》(RFC 2295)擴展,代表服務器存在內(nèi)部配置錯誤:被請求的協(xié)商變元資源被配置為在透明內(nèi)容協(xié)商中使用自己,因此在一個協(xié)商處理中不是一個合適的重點。
507服務器無法存儲完成請求所必須的內(nèi)容。這個狀況被認為是臨時的。WebDAV (RFC 4918)
509服務器達到帶寬限制。這不是一個官方的狀態(tài)碼,但是仍被廣泛使用。
510獲取資源所需要的策略并沒有沒滿足。(RFC 2774)



關于我們:

Infocode藍暢信息技術有限公司成功為多家世界財富500強企業(yè)以及其他著名品牌提供優(yōu)質(zhì)服務,是您靠譜的互聯(lián)網(wǎng)開發(fā)供應商。

服務客戶遍及北京、上海、杭州、深圳、廣州、天津、青島、南京、寧波、蘇州、無錫、廈門、重慶、西安等大中型城市及地區(qū)    為您提供H5開發(fā),小程序開發(fā),H5外包,微信開發(fā)外包,H5商城開發(fā),小程序商城開發(fā),網(wǎng)站開發(fā)外包,H5游戲開發(fā),小程序開發(fā)外包,小程序設計、APP開發(fā)外包,UI設計,SEO優(yōu)化,視頻后期制作等優(yōu)質(zhì)服務



本文地址:
更多內(nèi)容推薦:
專欄最新閱讀:
更多文章閱讀請至:技術專欄
Tips: 為您提供 微信開發(fā)H5開發(fā)、微信小程序開發(fā)、微信定制開發(fā)網(wǎng)站開發(fā)、小程序商城開發(fā)SEO網(wǎng)站優(yōu)化、視頻后期制作等定制化開發(fā)服務