⑴ apache 用httpclient模擬登錄時返回錯誤代碼HttpStatus.SC_UNAUTHORIZED（401），我用的是4.3.6版本的
HTTP 400 - 請求無效
HTTP 401.1 - 未授權：登錄失敗
HTTP 401.2 - 未授權：伺服器配置問題導致登錄失敗
HTTP 401.3 - ACL 禁止訪問資源
HTTP 401.4 - 未授權：授權被篩選器拒絕
HTTP 401.5 - 未授權：ISAPI 或 CGI 授權失敗
401 - 訪問被拒絕。IIS 定義了許多不同的 401 錯誤，它們指明更為具體的錯誤原因。這些具體的錯誤代碼在瀏覽器中顯示，但不在 IIS 日誌中顯示： ?? 401.1 - 登錄失敗。
?? 401.2 - 伺服器配置導致登錄失敗。
?? 401.3 - 由於 ACL 對資源的限制而未獲得授權。
?? 401.4 - 篩選器授權失敗。
?? 401.5 - ISAPI/CGI 應用程序授權失敗。
?? 401.7 – 訪問被 Web 伺服器上的 URL 授權策略拒絕。這個錯誤代碼為 IIS 6.0 所專用。
⑵ 關閉 apache 的用戶認證
你只需要在抄apache的配置文件中找到如下配置，將他們注釋掉即可
AllowOverride AuthConfig
AuthType Basic # 用戶認證類型
AuthName "Restricted Site" # 認證時顯示的名字
AuthUserFile /etc/httpd/conf/htpasswd # 認證時用戶的賬號密碼文件
AuthGroupFile /etc/httpd/conf/htgroup #基於組的認證
⑶ HTTP Status 401- type Status report message description This request requires HTTP authentication (
你先修改web.xml中，認證方式為DIGEST，然後用linux訪問試試，如果可以，那麼你就知道是什麼問題了
⑷ 解決windows下apache文件上傳失敗，讀寫的問題401
具體的php.ini完整配置信息：
⑸ apache rewrite 配置方法
.htaccess文件提供了針對每個目錄改變配置的方法。
top
.htaccess 文件*
相關模塊 相關指令
* core
* mod_authn_file
* mod_authz_groupfile
* mod_cgi
* mod_include
* mod_mime
* AccessFileName
* AllowOverride
* Options
* AddHandler
* SetHandler
* AuthType
* AuthName
* AuthUserFile
* AuthGroupFile
* Require
top
工作原理和使用方法*
.htaccess文件(或者"分布式配置文件")提供了針對每個目錄改變配置的方法，即在一個特定的目錄中放置一個包含指令的文件，其中的指令作用於此目錄及其所有子目錄。
說明：
如果需要使用.htaccess以外的其他文件名，可以用AccessFileName指令來改變。例如，需要使用.config ，則可以在伺服器配置文件中按以下方法配置：
AccessFileName .config
通常，.htaccess文件使用的配置語法和主配置文件一樣。AllowOverride指令按類別決定了.htaccess文件中哪些指令才是有效的。如果一個指令允許在.htaccess中使用，那麼在本手冊的說明中，此指令會有一個覆蓋項段，其中說明了為使此指令生效而必須在AllowOverride指令中設置的值。
例如，本手冊對AddDefaultCharset指令的闡述表明此指令可以用於.htaccess文件中(見"作用域"項)，而覆蓋項一行是FileInfo ，那麼為了使.htaccess中的此指令有效，則至少要設置 AllowOverride FileInfo 。
例子：
作用域 server config, virtual host, directory, .htaccess
覆蓋項 FileInfo
如果不能確定某個指令是否可以用於.htaccess文件，可以查閱手冊中對指令的說明，看在"作用域"行中是否有".htaccess" 。
top
(不)使用.htaccess文件的場合*
一般情況下，不應該使用.htaccess文件，除非你對主配置文件沒有訪問許可權。有一種很常見的誤解，認為用戶認證只能通過.htaccess文件實現，其實並不是這樣，把用戶認證寫在主配置文件中是完全可行的，而且是一種很好的方法。
.htaccess文件應該被用在內容提供者需要針對特定目錄改變伺服器的配置而又沒有root許可權的情況下。如果伺服器管理員不願意頻繁修改配置，則可以允許用戶通過.htaccess文件自己修改配置，尤其是ISP在同一個機器上運行了多個用戶站點，而又希望用戶可以自己改變配置的情況下。
雖然如此，一般都應該盡可能地避免使用.htaccess文件。任何希望放在.htaccess文件中的配置，都可以放在主配置文件的<Directory>段中，而且更高效。
避免使用.htaccess文件有兩個主要原因。
首先是性能。如果AllowOverride啟用了.htaccess文件，則Apache需要在每個目錄中查找.htaccess文件，因此，無論是否真正用到，啟用.htaccess都會導致性能的下降。另外，對每一個請求，都需要讀取一次.htaccess文件。
還有，Apache必須在所有上級的目錄中查找.htaccess文件，以使所有有效的指令都起作用(參見指令的生效)，所以，如果請求/www/htdocs/example中的頁面，Apache必須查找以下文件：
/.htaccess
/www/.htaccess
/www/htdocs/.htaccess
/www/htdocs/example/.htaccess
總共要訪問4個額外的文件，即使這些文件都不存在。(注意，這可能僅僅由於允許根目錄"/"使用.htaccess ，雖然這種情況並不多。)
其次是安全。這樣會允許用戶自己修改伺服器的配置，這可能會導致某些意想不到的修改，所以請認真考慮是否應當給予用戶這樣的特權。但是，如果給予用戶較少的特權而不能滿足其需要，則會帶來額外的技術支持請求，所以，必須明確地告訴用戶已經給予他們的許可權，說明AllowOverride設置的值，並引導他們參閱相應的說明，以免日後生出許多麻煩。
注意，在/www/htdocs/example目錄下的.htaccess文件中放置指令，與在主配置文件中<Directory /www/htdocs/example>段中放置相同指令，是完全等效的。
/www/htdocs/example目錄下的.htaccess文件：
/www/htdocs/example目錄下的.htaccess文件的內容：
AddType text/example .exm
httpd.conf文件中摘錄的內容：
<Directory /www/htdocs/example>
AddType text/example .exm
</Directory>
但是，把配置放在主配置文件中更加高效，因為只需要在Apache啟動時讀取一次，而不是在每次文件被請求時都讀取。
將AllowOverride設置為none可以完全禁止使用.htaccess文件：
AllowOverride None
top
指令的生效*
.htaccess文件中的配置指令作用於.htaccess文件所在的目錄及其所有子目錄，但是很重要的、需要注意的是，其上級目錄也可能會有.htaccess文件，而指令是按查找順序依次生效的，所以一個特定目錄下的.htaccess文件中的指令可能會覆蓋其上級目錄中的.htaccess文件中的指令，即子目錄中的指令會覆蓋父目錄或者主配置文件中的指令。
例子：
/www/htdocs/example1目錄中的.htaccess文件有如下內容：
Options +ExecCGI
(注意：必須設置"AllowOverride Options"以允許在.htaccess中使用"Options"指令)
/www/htdocs/example1/example2目錄中的.htaccess文件有如下內容：
Options Includes
由於第二個.htaccess文件的存在，/www/htdocs/example1/example2中的CGI執行是不允許的，而只允許 Options Includes ，它完全覆蓋了之前的設置。
將.htaccess合並到主配置文件中
正如在配置段(容器)中討論的那樣，.htaccess文件能夠覆蓋<Directory>段中對相應目錄的設置，但是也同樣會被主配置文件中其它類型的配置段所覆蓋。這個特性可以用來強制實施某些配置，甚至在AllowOverride已經許可的情況下。舉個例子來說，為了強迫在.htaccess中禁止腳本執行但不限制其它的情況下，可以這樣：
<Directory />
Allowoverride All
</Directory>
<Location />
Options +IncludesNoExec -ExecCGI
</Location>
top
認證舉例*
如果你只是為了知道如何認證，而直接從這里開始看的，有很重要的一點需要注意，有一種常見的誤解，認為實現密碼認證必須要使用.htaccess文件，其實是不正確的。把認證指令放在主配置文件的<Directory>段中是一個更好的方法，而.htaccess文件應該僅僅用於無權訪問主配置文件的時候。參見上述關於何時應該與何時不應該使用.htaccess文件的討論。
有此聲明在先，如果你仍然需要使用.htaccess文件，請繼續看以下說明。
.htaccess文件的內容：
AuthType Basic
AuthName "Password Required"
AuthUserFile /www/passwords/password.file
AuthGroupFile /www/passwords/group.file
Require Group admins
必須設置 AllowOverride AuthConfig 以允許這些指令生效。
更詳細的說明，請參見認證、授權、訪問控制。
top
伺服器端包含(SSI)舉例*
.htaccess文件的另一個常見用途是允許一個特定的目錄使用伺服器端包含(SSI)，可以在需要的目錄中放置.htaccess文件，並作如下配置：
Options +Includes
AddType text/html shtml
AddHandler server-parsed shtml
注意，必須同時設置 AllowOverride Options 和 AllowOverride FileInfo 以使這些指令生效。
更詳細的有關伺服器端包含的說明，請參見SSI指南。
top
CGI舉例*
可以通過.htaccess文件允許在特定的目錄中執行CGI程序，需要作如下配置：
Options +ExecCGI
AddHandler cgi-script cgi pl
另外，如下配置可以使給定目錄下的所有文件被視為CGI程序：
Options +ExecCGI
SetHandler cgi-script
注意，必須同時設置 AllowOverride Options 和 AllowOverride FileInfo 以使這些指令生效。
更詳細的有關CGI編程和配置的說明，請參見CGI指南。
top
疑難解答*
如果在.htaccess文件中的某些指令不起作用，可能有多種原因。
最常見的原因是AllowOverride指令沒有被正確設置，必須確保沒有對此文件區域設置 AllowOverride None 。有一個很好的測試方法，就是在.htaccess文件隨便增加點無意義的垃圾內容，如果伺服器沒有返回了一個錯誤消息，那麼幾乎可以斷定設置了 AllowOverride None 。
在訪問文檔時，如果收到伺服器的出錯消息，應該檢查Apache的錯誤日誌，可以知道.htaccess文件中哪些指令是不允許使用的，也可能會發現需要糾正的語法錯誤。
http://www.apachemanual.cn/howto/htaccess.html
⑹ 求助，編譯apache伺服器出問題
隨著網路技術的普及、應用和Web技術的不斷完善，Web服務已經成為互聯網上重要的服務形式之一。原有的客戶端/伺服器模式正在逐漸被瀏覽器/伺服器模式所取代。本文將重點Apache 伺服器的故障排除的技巧。
一、檢查配置文件的錯誤
Apache伺服器的設置文件位於/etc/httpd/conf/目錄下，傳統上使用三個配置文件httpd.conf,access.conf和srm.conf，來配置Apache伺服器的行為。在新版本的Apache中，所有的設置都被放在了httpd.conf中，因此只需要調整這個文件中的設置。其中99% Apache伺服器錯誤是配置文件有誤。
1 使用apachectl configtest命令
如果配置文件有錯誤，可以使用apachectl configtest命令，apachectl configtest命令可以檢查出所有語法錯誤和邏輯錯誤。
實例1
下面是一個配置文件樣例片斷：
Locatio
erver
tatu
SetHandler server
tatu
Order deny,allow
Deny from all
Allow from
192.168
149
</
Locatio
如果黑體部分的錯誤寫成了「<Location /server-status」少寫了一個 >。
apachectl configtest命令會檢查到這個問題，輸出如下：
apachectl configtest
Syntax error on line
918
of
etc
httpd
conf
httpd.conf:
Locatio
directive missing closing
2 使用服務管理工具
如果配置文件有錯誤，也可以使用GUI工具來查看。下面是實例1在GUI工具「服務配置「中的體現，如圖1 。
圖1 使用GUI工具檢查錯誤
二、 學會使用錯誤日誌 錯誤日誌是最重要的日誌文件，其文件名和位置取決於ErrorLog指令。Apache httpd將在這個文件中存放診斷信息和處理請求中出現的錯誤，由於這里經常包含了出錯細節以及如何解決，如果伺服器啟動或運行中有問題，首先就應該查看這個錯誤日誌。錯誤日誌是你的朋友。任何錯誤都會在錯誤日誌中有所記載，所以你應該首先查看它。如果你的網站空間提供者不允許訪問錯誤日誌，那麼你應該考慮換一個空間提供者。學會閱讀錯誤日誌，可以快速找出問題並快速解決。 1 錯誤日誌格式 Apache 默認的錯誤日誌配置如下： ErrorLog logs/error_log LogLevel warn 配置錯誤日誌相對簡單，只要說明日誌文件的存放路徑和日誌記錄等級即可。格式為： 日期和時間 錯誤等級 錯誤消息 2 日誌記錄等級 下面著重說說日誌記錄等級，包括八個級別。 1 級英文名稱emerg ，出現緊急情況使得該系統不可用，如系統宕機等 2 級alert 英文名稱，需要立即引起注意的情況 3 級 英文名稱crit ，危險情況的警告 4級 英文名稱error ，除了emerg 、alert、crit 的其他錯誤 5級英文名稱 warn。 警告信息 6級英文名稱 notice ，需要引起注意的情況，但不如error、warn 重要 7級英文名稱 info ，值得報告的一般消息 8級英文名稱 debug， 由運行於debug 模式的程序所產生的消息 錯誤日誌文件舉例 錯誤日誌的格式相對靈活，並可以附加文字描述。某些信息會出現在絕大多數記錄中，一個典型的例子是： [Wed Oct 11 14:32:52 2007] [error] [client 127.0.0.1] client denied by server configuration: /export/home/live/ap/htdocs/test 其中，第一項是錯誤發生的日期和時間；第二項是錯誤的嚴重性，LogLevel指令使只有高於指定嚴重性級別的錯誤才會被記錄；第三項是導致錯誤的IP地址；此後是信息本身，在此例中，伺服器拒絕了這個客戶的訪問。伺服器在記錄被訪問文件時，用的是文件系統路徑，而不是Web路徑。錯誤日誌中會包含類似上述例子的多種類型的信息。此外，CGI腳本中任何輸出到stderr的信息會作為調試信息原封不動地記錄到錯誤日誌中。用戶可以增加或刪除錯誤日誌的項。但是對某些特殊請求，在訪問日誌(access log)中也會有相應的記錄，比如上述例子在訪問日誌中也會有相應的記錄，其狀態碼是403，因為訪問日誌也可以定製，所以可以從訪問日誌中得到錯誤事件的更多信息。 了解錯誤代碼和錯誤提示 l 常用的錯誤響應代碼如下： 301 ：告知用戶請求的URL 已經永久的移動到新的URL，用戶可以記住新的URL，以便日後直接使用新的URL 進行訪問。 302 ：告知用戶請求的URL 臨時的移動到新的URL，用戶無需記住新的URL，如果省略錯誤響應代碼，默認就是此值。 303 ：告知用戶頁面已經被替換，用戶應該記住新的URL。 401 ：授權失敗，即密碼錯誤。 403 ：Access denied 存取錯誤，即不可以讀取該文件。 404 ：File not found 找不到文件。 410 ：告知用戶請求的頁面已經不再存在，使用此代碼時不應該使用重定向的URL 參數。 500 ：伺服器內部錯誤，可能是Web伺服器本身存在問題，也可能是編寫的程序出錯。 l 錯誤消息提示說明 「Invalid argument: core_output_filter: writing data to the network」 消息 Apache在可能的平台上使用系統調用sendfile來加速響應的發送。不幸的是，在某些系統上，Apache會在編譯時檢測sendfile的存在，即使它不能正常工作。這經常發生在使用網路或其他非標准文件系統時。這個問題的表現症狀包括上述信息出現在錯誤日誌里及對於非零長度文件請求發送零長度的響應。一般這個問題只發生在靜態文件上，因為動態文件通常用不到sendfile 。要修正這個問題，可用EnableSendfile指令關閉伺服器所有部分對sendfile的使用即可。同時參看EnableMMAP指令，對相似的問題有幫助。 「Premature end of script headers」 消息 大多數導致這個錯誤的CGI腳本問題將會向瀏覽器發送一個"Internal Server Error"錯誤信息。 「Permission denied」 消息 error_log中的"Permission denied"錯誤伴隨一個發送到客戶端的"Forbidden"信息通常表明違反了文件系統的許可權，而不是Apache HTTP的配置文件出了錯誤。檢查並確認用於運行子進程的User和Group有訪問導致問題的文件的足夠許可權。同時檢查一下導致問題的文件所在的目錄及其所有父目錄是否具有執行(搜索)許可權(也就是 chmod +x)。最近發行的 Fedora Core 和其它Linux發行版使用了SELinux進行額外的訪問控制，違反這些限制也會導致"Permission denied"消息。 "POST Method Not Allowed"消息 這說明Apache沒有被正確配置以執行CGI程序，重新閱讀配置Apache看看遺漏了什麼。 "Internal Server Error"消息 查閱Apache錯誤日誌，可以找到CGI程序產生的出錯消息"Premature end of script headers"。對此，需要檢查下列各項，以找出不能產生正確HTTP頭的原因。
1 檢查錯誤日誌！
Apache伺服器在遇到問題時會盡力做到對你有所幫助。在許多情況下，它會通過在錯誤日誌中寫入一條或多條消息來提供一些細節。有時這已經足夠讓你自己診斷和解決問題了(比如文件許可權或類似的問題)。錯誤日誌的默認位置在/usr/local/apache2/logs/error_log ，但是最後還是看看配置文件中的ErrorLog指令以確認錯誤日誌在你伺服器上的確切位置。
2 再一次檢查語法
Apache 配置文件是httpd.conf 長度通常在80-990行，幾乎99%Apache 故障是語法錯誤引起的。可以手工檢查/etc/httpd/conf/httpd.conf，也可以通過瀏覽器輸入：
http://192.168.1.12/server-info?config
獲取當前配置文件，如圖3 。
圖3 當前Apache伺服器配置文件
說明：此時系統會自動添加行號。
3 察看Apache的FAQ!
最新版本的Apache常見問題列表總是可以從Apache主站點得到，
4 察看Apache bug資料庫
大多數報告給Apache項目組的問題都記錄在bug資料庫中。在你添加一個新bug之前，請務必檢查已有的報告(打開的和關閉的)。如果你發現你的問題已經被報告了，請不要添加一個"我也是"那樣的報告。如果原始報告還沒有關閉，我們建議你經常周期性地來看看它。你也可以考慮與最初的提交者接觸，因為有可能會在郵件交流中發現沒有記錄在資料庫中的問題。
5 在某個用戶論壇中提問
Apache擁有一個活躍的、願意共享知識的用戶社區。參與這個社區通常是獲得解答的最快最好的辦法。
Apache用戶郵件列表：
6 提交問題報告到bug資料庫
如果做了以上幾個合適的步驟而沒有得到解答，那麼請務必讓httpd的開發者了解這個問題，到這里（
）提交bug報告。
7 獲取商業支持
⑺ 如何添加Apache伺服器用戶驗證AllowOverride AuthConfig
apache伺服器已經內置用戶驗證機制，大家只要適當的加以設置，便可以控制網站的某些部分要用戶驗證。
通常分為以下三步：
1、在apache的配置文件httpd.conf中聲明要進行驗證的目錄
2、在要進行驗證的目錄中創建.htaccess文件，在此文件中指明用於驗證的文件存放的位置
3、根據.htaccess指明的位置，用apache自帶的htpasswd命令創建用於驗證的文件
步驟說明：
假設要對/home/ddd這個目錄進行訪問控制。（這個目錄不在APACHE的主目錄中，因此要用alias 添加為虛擬目錄）
1、在apache的配置文件httpd.conf中聲明要進行驗證的目錄
編輯httpd.conf
LoadMole auth_mole moles/mod_auth.so #需要載入此模塊進行認證
Alias /test "/home/ddd" #添加為虛擬目錄
<Directory "/home/ddd">
Options Indexes MultiViews
AllowOverride All #允許用.htaccess文件中指定的驗證文件進行身份驗證
Order allow,deny
Allow from all
</Directory>
#AllowOverride all 表示進行身份驗證 這是關鍵的設置
此外，也可用AllowOverride AuthConfig
實例:
<VirtualHost *>
ServerName test.xxx.com
ServerAlias xxx.com 123.123.123.123
DocumentRoot /data/ddd/
<Directory "/home/ddd/COLumn/">
Options Indexes FollowSymlinks MultiViews
AllowOverride All
</Directory>
ErrorLog /error.log
</VirtualHost>
2、在要進行驗證的目錄中創建.htaccess文件，在此文件中指明用於驗證的文件存放的位置
在/home/ddd下創建.htaccess文件
vi /home/ddd/.htaccess，內容如下：
AuthName "請輸入用戶名及口令"
AuthType Basic
AuthUserFile /home/.htpasswd
require valid-user
#AuthName 描述，出現在驗證對話框標題欄中
#AuthUserFile /home/.htpasswd （指定驗證文件存放於/home中，文件名為.htpasswd，此文件具有隱含屬性，其中包括允許訪問的用戶名及密碼。
#require valid-user 使用驗證文件中的有效用戶進行驗證
也可使用 require user <用戶> 來指定特定用戶進行驗證
#密碼文件推薦取名為.htpasswd,因為apache默認系統對「.ht」開頭的文件默認不允許外部讀取，安全系數會高一些。
3、根據.htaccess指明的位置，用apache自帶的htpasswd命令創建用於驗證的文件
由於已經在第2步中指定驗證文件為/home/.htpasswd文件，所以下面創建這個文件
htpasswd -c /home/.htpasswd jp #創建.htpasswd文件，並添加用戶jp，會要求輸入口令
htpasswd /home/.htpasswd test #.htpasswd文件中添加第二個用戶：test）
也可以不通過交互方式，直接在命令行，將口令添加到.htpasswd文件中
htpasswd -bc /home/.htpasswd jp 111 （創建.htpasswd文件，並添加用戶jp，密碼為111）
htpasswd -b /home/.htpasswd test 222 （.htpasswd文件中添加第二個用戶：test 密碼為222）
#第一次創建用戶要用到-c 參數 第2次添加用戶，就不用-c參數，因為已經有.htpasswd文件，就不用再創建了。-b表示從命令行直接獲取參數值，添加到驗證文件.htpasswd中
如果想修改密碼，可以用如下命令：
htpasswd -m .htpasswd jp
對存放於.htpasswd文件中的用戶jp進行口令更改
⑻ 9月28日 centos6上httpd2.2基本配置 2和https的實現
Satisfy ALL|Any
ALL 客戶機IP和用戶驗證都需要通過才可以
Any客戶機IP和用戶驗證,有一個滿足即可
有三種實現方案：
基於ip：為每個虛擬主機准備至少一個ip地址
基於port：為每個虛擬主機使用至少一個獨立的port
基於FQDN：為每個虛擬主機使用至少一個FQDN
注意：一般虛擬機不要與main主機混用；因此，要使用虛擬主機，一般先禁用main主機
禁用方法：注釋中心主機的DocumentRoot指令即可
實驗步驟
總結： 基於FQDN的虛擬主機是生產中最常用的，一般我們在搭建虛擬主機時，要將main主機禁用，但如果不禁用，基於ip和埠號創建虛擬主機時main主機不會失效，訪問main主機的主站點文件時仍然可以訪問到，但如果基於FQDN創建時，main主機就會失效，這個時候如果訪問main主機的主站點時，就會跳到虛擬主機的主站點，並且誰是第一個虛擬主機時就會跳到誰那裡。因 此創建虛擬主機時最好將main主機禁用。當基於FQDN創建虛擬主機後，如果用http://172.18.21.106/，默認訪問的是第一個虛擬主機的主網站文件。
4、訪問這個網站就可以看到伺服器的狀態信息了
①http協議
http/0.9, http/1.0, http/1.1, http/2.0
http協議：stateless 無狀態
伺服器無法持續追蹤訪問者來源，也就是當你第二次訪問這個伺服器時，伺服器又不知道你是誰了。
解決http協議無狀態方法
cookie ：客戶端存放，分為兩種，一種為重cookie，一種為輕cookie，比如你在淘寶上買東西放到購物車里的東西，伺服器會將你的登錄信息和一些購物車里的信息以cookie的形式發送給你，並存儲在你的主機上，當你下次用同一個主機去訪問淘寶時，你會攜帶這個cookie信息，這時伺服器就知道你的身份了，這樣購物車里的東西就不會丟失，這種稱為重cookie，輕cookie只存放你的登錄信息。cookie是伺服器端生成後傳給客戶端的。在瀏覽器的選項/設置--->高級設置---->網頁內容高級設置中可以看到cookie。
session ：伺服器端存放，cookie要配合session使用，因為cookie只是存放在特定的主機，換了主機之後你之前訪問的信息，比如購物車裡面的信息又丟失了，session的作用就是將你的cookie裡面的登錄信息和網站訪問記錄到一個session表裡，並且存儲到伺服器上，下次你登錄淘寶的時候，伺服器就會和session裡面記錄的一些登錄信息對比，發現是你的登錄信息，就識別出了你，你的訪問記錄及購物車裡面的東西不會丟失。
http事務：一次訪問的過程
請求：request
響應：response
②HTTP請求報文和響應報文
③報文語法格式：
request報文
<method> <request-URL> <version>
<headers>
<entity-body>
response報文
<version> <status> <reason-phrase>
<headers>
<entity-body>
method: 請求方法，標明客戶端希望對伺服器資源執行的動作。
Method 方法：
GET：從伺服器獲取一個資源
HEAD：只從伺服器獲取文檔的響應首部
POST：向伺服器輸入數據，比如字元串等，通常會再由網關程序繼續處理
PUT：將請求的主體部分存儲在伺服器中，如上傳文件
DELETE：請求刪除伺服器上指定的文檔
TRACE：追蹤請求到達伺服器中間經過的代理伺服器
OPTIONS：請求伺服器返回對指定資源支持使用的請求方法
version:
HTTP/<major>.<minor>，比如HTTP/1.1---目前用的比較多的協議類型
status:
三位數字，如200，301, 302, 404, 502; 標記請求處理過程中發生的情況
reason-phrase：
狀態碼所標記的狀態的簡要描述
headers：
每個請求或響應報文可包含任意個首部；每個首部都有首部名稱，後面跟一個冒號，而後跟一個可選空格，接著是一個值
entity-body：請求時附加的數據或響應時附加的數據
④http協議狀態碼分類
status(狀態碼)：
1xx：100-101信息提示
2xx：200-206成功
3xx：300-305重定向
4xx：400-415錯誤類信息，客戶端錯誤
5xx：500-505錯誤類信息，伺服器端錯誤
常用的狀態碼
200：成功，請求數據通過響應報文的entity-body部分發送;OK
301：請求的URL指向的資源已經被刪除；但在響應報文中通過首部Location指明了資源現在所處的新位置；Moved Permanently，表示永久重定向，在配置文件里設置網站的別名時就是永久的重定向。
302：響應報文Location指明資源臨時新位置Moved Temporarily，是臨時重定向。
304：客戶端發出了條件式請求，但伺服器上的資源未曾發生改變，則通過響應此響應狀態碼通知客戶端；Not Modified，表示伺服器端是利用緩存把資源發送給客戶端，可以用ctrl+f5強制刷新。
401：需要輸入賬號和密碼認證方能訪問資源；Unauthorized，基於basic認證登錄時會在日誌裡面發現這個狀態碼。
403：請求被禁止；Forbidden，一個原因是伺服器的配置文件裡面設定了允許哪些主機訪問，另外一個原因可能是你訪問的文件夾文件系統的許可權不足。
404：伺服器無法找到客戶端請求的資源；Not Found
500：伺服器內部錯誤；Internal Server Error
502：代理伺服器從後端伺服器收到了一條偽響應，如無法連接到網關；Bad Gateway
503 :服務不可用，臨時伺服器維護或過載，伺服器無法處理請求
504:網關超時
總結：method是客戶端請求伺服器端要做什麼，而狀態碼是伺服器端返回給客戶端的狀態信息。
更多信息可以參考火狐瀏覽器： https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status
⑤http協議首部
首部的分類：通用首部、請求首部、響應首部、實體首部、擴展首部
通用首部：
Date: 報文的創建時間
Connection：連接狀態，如keep-alive, close
Via：顯示報文經過的中間節點（代理，網關）
Cache-Control：控制緩存，如緩存時長
MIME-Version:發送端使用的MIME版本
請求首部：
Accept：通知伺服器自己可接受的媒體類型
Accept-Charset：客戶端可接受的字元集
Accept-Encoding：客戶端可接受編碼格式，如gzip
Accept-Language：客戶端可接受的語言
Client-IP: 請求的客戶端IP
Host: 請求的伺服器名稱和埠號
Referer：跳轉至當前URI的前一個URL
User-Agent：客戶端代理，瀏覽器版本
curl [options] [URL...]
-A/--user-agent <string> 設置用戶代理發送給伺服器
-e/--referer<URL> 來源網址
--cacert<file> CA證書(SSL)
-k/--insecure 允許忽略證書進行SSL 連接
--compressed 要求返回是壓縮的格式
-H/--header <line>自定義首部信息傳遞給伺服器
-i顯示頁面內容，包括報文首部信息
-I/--head 只顯示響應報文首部信息
-D/--mp-header <file>將url的header信息存放在指定文件中
--limit-rate <rate> 設置傳輸速度
--basic 使用HTTP基本認證
-u/--user <user[:password]>設置伺服器的用戶和密碼
-L 如果有3xx響應碼，重新發請求到新位置，進行強制重定向
-o<file> 將網路文件保存為指定的文件中
-O使用URL中默認的文件名保存文件到本地
-0/--http1.0 使用HTTP 1.0
-C -選項可對文件使用斷點續傳功能
-c/--cookie-jar <file name> 將url中cookie存放在指定文件中
-x/--proxy <proxyhost[:port]> 指定代理伺服器地址
-X/--request <command> 向伺服器發送指定請求方法
-U/--proxy-user <user:password> 代理伺服器用戶和密碼
-T 選項可將指定的本地文件上傳到FTP伺服器上
--data/-d 方式指定使用POST方式傳遞數據
elinks工具：
elinks[OPTION]... [URL]...
-mp: 非互動式模式，將URL的內容輸出至標准輸出
-source:列印源碼
用法和links相同。
示例
使用deflate_mole模塊壓縮頁面優化傳輸速度
適用場景：
(1) 節約帶寬，額外消耗CPU；同時，可能有些較老瀏覽器不支持
(2) 壓縮適於壓縮的資源，例如文本文件
Level of compression (Highest 9 -Lowest 1)
DeflateCompressionLevel 9
示例
https：http over ssl
SSL會話的簡化過程
(1) 客戶端發送可供選擇的加密方式，並向伺服器請求證書
(2) 伺服器端發送證書以及選定的加密方式給客戶端，這個證書是用CA的私鑰加密的伺服器的公鑰以及證書的有效期等信息，也就是CA數字簽名的證書。
(3) 客戶端取得證書並進行證書驗證
如果信任給伺服器發證書的CA，客戶端會實驗得到CA的公鑰
(a) 驗證證書來源的合法性；用CA的公鑰解密證書上數字簽名
(b) 驗證證書的內容的合法性：完整性驗證
(c) 檢查證書的有效期限
(d) 檢查證書是否被吊銷
(e) 證書中擁有者的名字，與訪問的目標主機要一致
(4) 客戶端生成臨時會話密鑰（對稱密鑰），並使用伺服器端的公鑰加密此數據發送給伺服器，完成密鑰交換
(5) 服務用此密鑰加密用戶請求的資源，響應給客戶端
實現過程如下：
將http請求轉發至https的URL
重定向
Redirect [status] URL-path URL
status狀態分為兩種：
Permanent(永久重定向):Returnsa permanent redirect status (301) indicating that the resource has moved permanently
Temp(臨時重定向):Returnsa temporary redirect status (302). This is the default
示例：
HSTS:HTTP Strict Transport Security
伺服器端配置支持HSTS後，會在給瀏覽器返回的HTTP首部中攜帶HSTS欄位。瀏覽器獲取到該信息後，會將所有HTTP訪問請求在內部做307跳轉到HTTPS，而無需任何網路過程
支持HSTS後只需要兩步就實現跳轉，而且只有第一次跑到伺服器端進行跳轉，下一次訪問就直接在瀏覽器端就進行跳轉了，瀏覽器已經記住了這個網站的伺服器支持HSTS，這樣既提高了效率又比較安全
HSTS preload list
是Chrome瀏覽器中的HSTS預載入列表，在該列表中的網站，使用Chrome瀏覽器訪問時，會自動轉換成HTTPS。Firefox、Safari、Edge瀏覽器也會採用這個列表，也就是解決了上面的第一次跑到伺服器端進行跳轉的問題，直接在瀏覽器端就進行了跳轉，更安全，不過這個是瀏覽器自己設置的功能。
實驗
⑼ .htaccess文件的常見用法（301、404等配置）
body{
line-height:200%;
}
.htaccess文件的常見用法（301、404等配置）
.htaccess文件是apache伺服器中的一個配置文件，它的功能是網站目錄的配置。通過.htaccess文件，可以實現以下功能：網頁301重定向、防盜鏈、自定義404錯誤頁面、用戶認證和授權、禁止目錄列表、配置默認文檔等功能。
.htaccess文件實現301重定向
RewriteEngine
on
rewritecond
%{http_host}
^zzidc.com[nc]
rewriterule
^(.*)$
http://zzidc.com/$1
[L,R=301]
.htaccess文件實現404
<Files
~
"^.(htaccess|htpasswd)$">
deny
from
all
</Files>
ErrorDocument
404
/404.html
//此段為功能代碼
order
deny,allow
.htaccess文件實現用戶認證和授權
AllowOverride
None
//不使用“.htaccess文件”
AuthType
Basic
//認證類型為基本認證
AuthName"this
is
a
test
directory.
please
login:"
//設置認證領域說明
AuthUserFile/etc/httpd/mypasswd
//指定認證口令文件的所在目錄和名稱
Require
valid-user
//授權給認證口令文件中的所有用戶
.htaccess文件實現防盜鏈
RewriteEngine
on
RewriteCond
%{
HTTP_REFERER
}
!^$
RewriteCond
%{
HTTP_REFERER
}
!^http://(www.)?mydomain.com/.*$
[NC]
RewriteRule
.(gif&line;jpg)$
http://www.mydomain.com/替代名
[R,L]
.htaccess文件禁止目錄列表
<Files
~
".*">
Order
allow,deny
Deny
from
all
</Files>
Options
-Indexes
//此段為功能代碼
.htaccess文件配置默認文檔
<Files
~
"^.(htaccess|htpasswd)$">
deny
from
all
</Files>
DirectoryIndex
index.html
index.php
//此段為功能代碼
order
deny,allow
推薦閱讀：iis安全防盜鏈設置
⑽ svn apache 配置後瀏覽器訪問，不停的提示輸入用戶名密碼,centos下配的，取消了就401錯誤
1、檢查是否在apache的httpd.conf中正確指定了用戶密碼文件？
2、檢查是否成功添加了Apache用戶帳號？
3、檢查是否輸入了正確的用戶名和密碼？