1、forward和redirect的區別
1.從位址列顯示來說
forward是伺服器請求資源,伺服器直接訪問目標地址的URL,把那個URL的響應內容讀取過來,然後把這些內容再發給瀏覽器.瀏覽器根本不知道伺服器傳送的內容從哪裡來的,所以它的位址列還是原來的地址.
redirect是服務端根據邏輯,傳送一個狀態碼,告訴瀏覽器重新去請求那個地址.所以位址列顯示的是新的URL.
2.從資料共享來說
forward:轉發頁面和轉發到的頁面可以共享request裡面的資料.
redirect:不能共享資料.
3從運用地方來說
forward:一般用於使用者登陸的時候,根據角色轉發到相應的模組.
redirect:一般用於使用者登出登陸時返回主頁面和跳轉到其它的網站等.
4.從效率來說
forward:高.
redirect:低.

2、session和cookie的區別，如何實現自動登入
1、session儲存在伺服器，客戶端不知道其中的資訊；cookie儲存在客戶端，伺服器能夠知道其中的資訊。
2、session中儲存的是物件，cookie中儲存的是字串。
3、session不能區分路徑，同一個使用者在訪問一個網站期間，所有的session在任何一個地方都可以訪問到。而cookie中如果設定了路徑引數，那麼同一個網站中不同路徑下的cookie互相是訪問不到的。
4、session需要藉助cookie才能正常工作。如果客戶端完全禁止cookie，session將失效。（ps：Java可以通過URL，進行sessionId的傳遞，而不是非得用cookie）
5、session在使用者會話結束後就會關閉了，但cookie因為儲存在客戶端，可以長期儲存

自動登入：
如果沒有cookie資訊,校驗後把資訊（使用者名稱，密碼等）放在cookie裡面。
如果有cookie，則讀取cookie裡的使用者名稱和密碼或者其它資訊，然後根據讀取的使用者名稱和密碼進行校驗。

4、Http header內容
HTTP Headers是HTTP請求和相應的核心，它承載了關於客戶端瀏覽器，請求頁面，伺服器等相關的資訊。
基礎知識：Http的請求格式如下:
[request line] 主要包含三個資訊：1、請求的型別（GET或POST），2、要訪問的資源（如\res\img\a.jif），3、Http版本（http/1.1）
[header ] 用來說明伺服器要使用的附加資訊
[blank line ] 這是Http的規定，必須空一行
[request-body] 請求的內容資料

當你在瀏覽器位址列裡鍵入一個url，你的瀏覽器將會類似如下的http請求：
GET /tutorials/other/top-20-mysql-best-practices/ HTTP/1.1
Host: net.tutsplus.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: PHPSESSID=r2t5uvjq435r4q7ib3vtdjq120
Pragma: no-cache
Cache-Control: no-cache

第一行被稱為“Request Line” 它描述的是這個請求的基本資訊，剩下的就是HTTP headers了。

請求完成之後，你的瀏覽器可能會收到如下的HTTP響應：

HTTP/1.x 200 OK
Transfer-Encoding: chunked
Date: Sat, 28 Nov 2009 04:36:25 GMT
Server: LiteSpeed
Connection: close
X-Powered-By: W3 Total Cache/0.8
Pragma: public
Expires: Sat, 28 Nov 2009 05:36:25 GMT
Etag: “pub1259380237;gz”
Cache-Control: max-age=3600, public
Content-Type: text/html; charset=UTF-8
Last-Modified: Sat, 28 Nov 2009 03:50:37 GMT
X-Pingback: http://net.tutsplus.com/xmlrpc.php
Content-Encoding: gzip
Vary: Accept-Encoding, Cookie, User-Agent

5、get和post的區別
1、Get是從伺服器端獲取資料，Post則是向伺服器端傳送資料。
2、在客戶端，Get方式通過URL提交資料，在URL位址列可以看到請求訊息，該訊息被編碼過；Post資料則是放在Html header內提交。
3、對於Get方式，伺服器端用Request.QueryString獲取變數的值；對用Post方式，伺服器端用Request.Form獲取提交的資料值。
4、Get方式提交的資料最多1024位元組，而Post則沒有限制。
5、Get方式提交的引數及引數值會在位址列顯示，不安全，而Post不會，比較安全。
http://www.nowamagic.net/librarys/veda/detail/1919

6、40*錯誤、50*錯誤
HTTP狀態碼
•200 用來表示請求成功.
•300 來表示重定向.
•400 用來表示請求出現問題.
•500 用來表示伺服器出現問題.

200 成功 （OK）
前文已經提到，200是用來表示請求成功的
206 部分內容 （Partial Content）
如果一個應用只請求某範圍之內的檔案，那麼就會返回206
這通常被用來進行下載管理，斷點續傳或者檔案分塊下載。

400 - 錯誤的請求。
401 - 訪問被拒絕。IIS 定義了許多不同的 401 錯誤，它們指明更為具體的錯誤原因。這些具體的錯誤程式碼在瀏覽器中顯示，但不在 IIS 日誌中顯示： ·401.1 - 登入失敗。
404 - 未找到。 ·404.0 -（無） – 沒有找到檔案或目錄。
·404.1 - 無法在所請求的埠上訪問 Web 站點。
·404.2 - Web 服務擴充套件鎖定策略阻止本請求。
·404.3 - MIME 對映策略阻止本請求。
405 - 用來訪問本頁面的 HTTP 謂詞不被允許（方法不被允許）

JSP程式404錯誤的解決方法如下：
1、web應用沒有部署成功：從控制檯()的deployments下面看，要注意狀態。如果沒有部署成功，可以到控制檯（啟動伺服器的命令列視窗）檢視錯誤。如果使用了Tomcat，則通過，再選擇管理介面。
2、Web應用的名字（實際上是訪問方式，通常是context-root），檢視方式：在工程上點右鍵，選擇“Properties”，選擇MyEclipseàWeb，介面中的Web Context-root.
3、資源的名字（JSP和servlet）
　　如果是JSP檔案，仔細看檔名字是否寫錯。（在MyEclipse中開發的時候，JSP檔案放在web-root中，不能放錯，如果有其他資料夾，訪問方式中要寫出資料夾）如果沒有錯誤，仔細看檔案中是否通過jsp:forward或者jsp:include等訪問方式訪問了其他檔案，看其他檔案是否存在。
　　如果是Servlet，檢視web.xml文擋：
﹤servlet-mapping﹥
﹤servlet-name﹥LoginServlet﹤/servlet-name﹥
﹤url-pattern﹥/login﹤/url-pattern﹥
﹤/servlet-mapping﹥
　　其中url-pattern的內容決定了訪問方式。
　　如果這個Servlet的配置沒有錯誤，要檢視該Servlet檔案中是否訪問了其他檔案，檢視所訪問的檔案是否存在。
4、如果上面這些錯誤都沒有，可能是系統的快取問題，包括客戶端瀏覽器和伺服器的臨時檔案。解決方法：重新啟動瀏覽器，重新編譯工程（ProjectàClean），重新部署，關閉應用伺服器，重新啟動應用伺服器，重新訪問。
　
7、簡述mvc模式
MVC英文即Model-View-Controller，即把一個應用的輸入、處理、輸出流程按照Model、View、Controller的方式進行分離，這樣一個應用被分成三個層——模型層、檢視層、控制層。
檢視
　　檢視(View)代表使用者互動介面，對於Web應用來說，可以概括為HTML介面，但有可能為XHTML、XML和Applet。隨著應用的復 雜性和規模性，介面的處理也變得具有挑戰性。一個應用可能有很多不同的檢視，MVC設計模式對於檢視的處理僅限於檢視上資料的採集和處理，以及使用者的請 求，而不包括在檢視上的業務流程的處理。業務流程的處理交予模型(Model)處理。比如一個訂單的檢視只接受來自模型的資料並顯示給使用者，以及將使用者界 面的輸入資料和請求傳遞給控制和模型。

模型
　　模型(Model)：就是業務流程/狀態的處理以及業務規則的制定。業務流程的處理過程對其它層來說是黑箱操作，模型接受檢視請求的資料，並返 回最終的處理結果。業務模型的設計可以說是MVC最主要的核心。目前流行的EJB模型就是一個典型的應用例子，它從應用技術實現的角度對模型做了進一步的 劃分，以便充分利用現有的元件，但它不能作為應用設計模型的框架。它僅僅告訴你按這種模型設計就可以利用某些技術元件，從而減少了技術上的困難。對一個開 發者來說，就可以專注於業務模型的設計。MVC設計模式告訴我們，把應用的模型按一定的規則抽取出來，抽取的層次很重要，這也是判斷開發人員是否優秀的設 計依據。抽象與具體不能隔得太遠，也不能太近。MVC並沒有提供模型的設計方法，而只告訴你應該組織管理這些模型，以便於模型的重構和提高重用性。我們可 以用物件程式設計來做比喻，MVC定義了一個頂級類，告訴它的子類你只能做這些，但沒法限制你能做這些。這點對程式設計的開發人員非常重要。
　　業務模型還有一個很重要的模型那就是資料模型。資料模型主要指實體物件的資料 儲存（持續化）。比如將一張訂單儲存到資料庫，從資料庫獲取訂單。我們可以將這個模型單獨列出，所有有關資料庫的操作只限制在該模型中。

控制
　　控制(Controller)可以理解為從使用者接收請求, 將模型與檢視匹配在一起，共同完成使用者的請求。劃分控制層的作用也很明顯，它清楚地告訴你，它就是一個分發器，選擇什麼樣的模型，選擇什麼樣的檢視，可以 完成什麼樣的使用者請求。控制層並不做任何的資料處理。例如，使用者點選一個連線，控制層接受請求後, 並不處理業務資訊，它只把使用者的資訊傳遞給模型，告訴模型做什麼，選擇符合要求的檢視返回給使用者。因此，一個模型可能對應多個檢視，一個檢視可能對應多個 模型。
　　模型、檢視與控制器的分離，使得一個模型可以具有多個顯示檢視。如果使用者通過某個檢視的控制器改變了模型的資料，所有其它依賴於這些資料的檢視 都應反映到這些變化。因此，無論何時發生了何種資料變化，控制器都會將變化通知所有的檢視，導致顯示的更新。這實際上是一種模型的變化-傳播機制。