| 參數 | 默認值 | 描述 |
| WebLogicHost （如果代理到單個WebLogic服務器，那么應該設置該參數） | none | HTTP請求被遞交到該WebLogic Server主機（或者是定義在WebLogic Server中運行的類似于Web server的虛擬主機名）如果使用集群，那么應該使用WebLogicCluster參數而不是WebLogicHost參數。 |
| WebLogicPort （如果代理到單個WebLogic服務器，那么應該設置該參數） | none | WebLogic服務器監聽WebLogic連接請求的端口。（如果在插件與WebLogic服務器之間使用SSL，那么應該把該參數設置為SSL監聽端口（見8-4頁的"配置監聽端口"）并將SecureProxy參數設置為ON）。 如果使用WebLogic集群，那么應該設置WebLogicCluster參數而不是WebLogicPort參數。 |
| WebLogicCluster （如果代理到一個WebLogic服務器集群，那么必須設置該參數） | none | 集群中的WebLogic服務器列表，用于負載平衡目的。該列表由逗號分隔開的host:port組成。例如： WebLogicCluster myweblogic.com:7001, yourweblogic.com:7001,theirweblogic.com:7001 如果插件與WebLogic服務器之間使用SSL協議，那么將端口號設置為SSL監聽端口（見8-3頁的"配置監聽端口"）并將SecureProxy參數設置為ON。 應該用該參數取代WebLogicHost與WebLogicPort參數，WebLogic Server首先查找WebLogicCluster參數，如果沒有找到該參數，它將尋找并使用WebLogicHost與WebLogicPort參數。 插件對所有可用的集群成員進行輪詢。該參數所指定的集群列表是服務器與插件共同維護的動態列表的初始值。WebLogic服務器與插件將根據新加入的、失敗的以及恢復的集群成員的情況動態地更新集群列表。 如果將DynamicServerList參數設置為OFF（只適用于Microsoft Internet Information Server），那么集群列表的動態更新被禁用。插件將請求導向集群中最初創建cookie的那個服務器上（請求包含cookie、URL-encoded會話或存于POST數據中的會話信息）。 |
| PathTrim | none | 在請求被轉交到WebLogic服務器之前，被插件從原始URL中裁剪掉的字符串。例如：如果原始URL為 http://myWeb.server.com/weblogic/foo被傳遞到插件進行解析且PathTrim參數被設置為/weblogic，那么傳遞到WebLogic服務器的URL變為：http://myweblogic.server.com:7001/foo |
| PathPrepend | null | 加在原始URL前的前綴字符串，該動作發生在PathTrim被裁剪后，請求轉向WebLogic服務器之前。 |
| ConnectTimeoutSecs | 10 | 插件進行WebLogic服務器主機連接嘗試的時間上限。該值應該大于ConnectRetrySecs參數。如果超過ConnectTimeoutSecs還沒能連接成功，即使進行了適當次數的連接重試（見ConnectRetrySecs參數），也將把HTTP 503/Service Unavailable響應返回給客戶端。 可以使用ErrorPage參數定制錯誤響應。 |
| ConnectRetrySecs | 2 | 該參數以秒為單位，設置了兩次WebLogic Server主機（或集群中的所有服務器）連接嘗試之間，插件的休眠時間。該參數的值應該小于ConnectTimeoutSecs。插件在返回HTTP 503/Service Unavailable響應之前，它將進行的連接次數為ConnectTimeoutSecs除以ConnectRetrySecs所得的值。 如果不希望重試連接，那么應該將ConnectRetrySecs值應該與ConnectTimeoutSecs相等。不過，插件會至少進行兩次連接嘗試。 可以用ErrorPage參數定制錯誤響應。 |
| Debug | OFF | 設置調試操作時的日志類型。在生產系統中不建議你開啟這些調試選項。 在UNIX系統中，調試信息被寫到/tmp/wlproxy.log文件中；在Windows NT系統，調試信息被寫到c:\temp\wlproxy.log文件中，通過WLLogFile參數，你可以使用其他路徑下的其他文件覆蓋文件名、路徑參數。你可以設置以下日志選項（其中HFC, HTW, HFW, HTC可以聯合使用，它們之間用逗號隔開，如"HFC, HTW"）； ON 插件只記錄報告性消息與錯誤消息 OFF 不記錄調試信息 HFC 記錄來自客戶端消息、報告性消息以及錯誤消息的消息頭。 HTW 記錄從weblogic發送來的消息頭，報告性消息與錯誤消息 HFW 記錄來自weblogic服務器消息的消息頭，報告性消息與錯誤消息 HTC 記錄發送到客戶端消息的消息頭，報告性消息與錯誤消息 ALL 記錄發送到客戶端以及客戶端發送的消息的頭，發送到WebLogic服務器以及WebLogic服務器發送的消息頭，報告性消息，錯誤消息 |
| WLLogFile | 參見Debug參數 | 指明當Debug參數為ON時，產生日志文件的路徑和文件名，在設置該參數前，必須創建相應目錄。 |
| DebugConfigInfo | OFF | 啟用特殊查詢參數"_WebLogicBridgeConfig"。該參數可以被用來了解插件的配置參數的細節。 例如，如果把DebugConfigInfo設置為ON，那么"_WebLogicBridgeConfig"被啟用。發送一個包含查詢字符串?_WebLogicBridgeConfig的請求，插件將收集配置信息有運行時的統計信息并將這些信息返回給瀏覽器。在處理該請求時，插件沒有連接到WebLogic服務器。 該參數只應嚴格用于調試目的。消息的輸出格式隨版本的變化而不同。為了安全起見，在生產環境中應該將該參數設置為OFF。 |
| StatPath（Microsoft Internet Information Server 插件沒有這個參數。） | false | 如果把該參數設置為真，插件在把請求傳遞到WebLogic服務器之前檢查被轉換的路徑是否存在或及其訪問權限（"Proxy-Path-Translated"）。如果文件不存在，將把HTTP 404 File Not Found響應返回給客戶端。如果文件存在，但它的權限不是world-readable，那么將返回HTTP 403/Forbidden響應。這兩種情況下Web服務器處理這些響應的缺省機制是執行響應的體內容。如果WebLogic服務器的Web應用與Web服務器具有相同的文檔根，那么該選項非常有用。 可以使用ErrorPage參數定制錯誤響應。 |
| ErrorPage | none | 可以制作自己的錯誤響應頁面，在Web服務器不能將請求代理到WebLogic服務器時使用。 設置該參數的方式有兩種：
- 作為相對URI（文件名）。插件自動將返回錯誤的Web應用的上下文路徑加到URI中。對錯誤頁面的請求是否回代理到WebLogic服務器取決于你對代理的配置（是MIME類型式代理還是路徑式代理）。
- 作為絕對URI（建議）。使用錯誤頁面的絕對路徑能夠使請求總是被代理到WebLogic服務器中的正確資源上。例如： http://host:port/myWebApp/ErrorPage.html
|
| HungServerRecoverSecs | 300 | 定義了插件等待WebLogic服務器響應請求的時間。在等待了HungServerRecoverSecs時間后，插件還沒有得到服務器的響應，那么它將宣布該服務器已經死機并失敗轉移到下一個服務器。應該把該參數設置為一個較大的值。如果所設置的值小于servlets進行處理的時間，那么會得到意想不到的后果。 最小值為：10 最大值為：600 |
| Idempotent | ON | 如果該參數設置為ON，那么當服務器在指定的HungServerRecoverSecs時間沒有響應，那么插件將進行容錯處理。如果設置為OFF，插件將不進行失敗轉移。如果所使用的是Netscape Enterprise Server插件或Apache HTTP Server插件，不同的URL與MIME類型可以有不同的Idempotent參數設置。 |
| CookieName | JSESSIO NID | 如果改變了WebLogic服務器Web應用中的WebLogic服務器會話cookie的名字，那么相應地應該將插件的CookieName參數設置為相同的值。WebLogic會話cookie的名字在特定于WebLogic的分發描述符的<session-descriptor>元素中定義 |
| DefaultFileName | none | 如果URI為"/"，插件將執行以下步驟： 1．裁剪掉PathTrim參數所指定的路徑 2．在后面加上DefaultFileName所指定的文件名 3．在前面加上PathPrepend參數所指定的值這樣處理可以防止WebLogic服務器的重定向。將DefaultFileName設置為代理WebLogic服務器的Web應用的缺省歡迎頁面。例如，如果DefaultFileName被設置為welcome.html，那么下面這個HTTP請求： http://somehost/weblogic 變為：http://somehost/weblogic/welcome.html。只有當所有被重定向的web應用指定相同的歡迎頁面， 該參數才起作用。可以參見以下頁面的"Configuring Welcome Pages"部分： http://e-docs.bea.com/wls/docs61/webapp/components 對于Apache用戶，所使用的是Stronghold或Raven的版本，在Location塊中定義參數，而非IfModule塊中 |
| MaxPostSize | -1 | POST數據的允許的最大長度。如果內容的長度超過MaxPostSize，插件將返回一個錯誤消息。如果設置為-1，將不檢查POST數據的長度。設置該參數可以防止通過發送大量數據使服務器過載的"拒絕服務攻擊"。 |
| MatchExpression （該參數只適用于Apache HTTP服務器） | none | 如果采用MIME類型方式代理，應該在一個IfModule塊中使用MatchExpression參數設置文件名模式。 下面的一個例子說明了使用MIME類型方式的代理： <IfModule mod_weblogic.c> MatchExpression *.jsp WebLogicHost=myHost|paramName=value </IfModule> 下面的一個例子說明了使用路徑方式的代理： <IfModule mod_weblogic.c> MatchExpression /weblogicWebLogicHost=myHost|paramName=value </IfModule> |
| FileCaching | ON | 當該參數設置為ON，如果請求中的POST數據大于2084個字節，那么POST數據保存在硬盤的一個臨時文件中，然后以8192字節為單位傳給WebLogic服務器。但將FileCaching設置為ON，可能引起的問題是瀏覽器上將顯示一個進展條表明正在進行下載。即使文件還在傳輸，瀏覽器也會顯示下在已經完成。 如果該參數設置為OFF，那么當POST數據大于2084字節時，數據保存在內存中并以8192字節為單位發送到WebLogic服務器。將參數設置為OFF可能會引起問題。因為插件不能進行失敗轉移，因此如果請求被處理時WebLogic 服務器宕機了，那么數據將被丟失。 |
| WlForwardPath （只有Microsoft IIS才需要定義該單數） | null | 如果WLForwardPath設置為"/"，那么所有請求都被代理到WebLogic服務器。如果只想代理以特定字符串開頭的請求，那么應該將WlForwardPath參數設置為這個字符串。例如，將WlForwardPath設置為/webogic，那么所有以/weblogic開始的請求都將被代理到WebLogic服務器。 如果采用路徑方式的代理，那么必須設置該參數。可以為該參數設置多個字符串，字符串之間用逗號隔開，例如：WlForwardPath=/weblogic,/bea。 |
| KeepAliveSecs （不要為Apache HTTP服務器版本1.3.x定義該參數） | 30 | 該參數定義了隔多長時間后，插件與WebLogic服務器之間的非活動連接將被關閉。要使該參數生效，KeepAliveEnabled參數應該設置為true。 該參數的值應該小于或等于在管理控制臺的Server/HTTP標簽頁中Duration字段的值，或者是服務器Mbean中的keepAliveSecs屬性的值。 |
| KeepAliveEnabled | True | 啟用插件與WebLogic服務器之間的連接池。 |
| QueryFromRequest （只適用于Apache HTTP服務器） | OFF | 如果該參數設置為ON，那么Apache插件使用（request_rec *）r->the request將查詢字符串傳遞到WebLogic服務器。（詳細信息，請參見Apache文檔。）這種行為在以下場合非常有用： 當Netscape 版本4.x瀏覽器發出的請求的查詢字符串中包含空格。 如果你在HP上使用Raven Apache 1.5.2 如果該參數設置為OFF，那么Apache插件使用（request_rec *）r->args將查詢字符串傳遞到WebLogic服務器。 |
| MaxSkips （在Apache 1.3 中不可用） | 10 | 只有當DynamicServerList設置為OFF時，該參數的設置才生效。如果WebLogicCluster參數所設置的列表或由WebLogic服務器返回的動態集群列表中的WebLogic服務器失敗了，那么該失敗的服務器被標記為"壞的"，同時插件將連接到列表中的下一個服務器中。 MaxSkip設置了插件重試"壞"服務器的次數。每當插件接收到一個唯一請求（即不包含cookie的請求）時，它會連接到列表中的一個新服務器上 |
| DynamicServerList （只能在Microsfot IIS中設置該參數） | ON | 如果該參數設置為OFF，在對由插件所代理的請求進行負載平衡時，不使用動態集群列表，而是使用WebLogicCluster參數指定的靜態列表。通常情況下，該參數應該設置為ON。將該參數設置為ON，可能會產生以下影響：
- 如果靜態列表中的一或多個服務器失敗了，那么插件可能會因為重試連接到失效服務器而導致性能的降低。
- 當你在集群中新增了一個服務器，如果不重新定義這個參數，插件就不能將請求代理到這個新服務器上。WebLogic服務器會自動地將新服務器加到動態服務器列表，從而使新服務器成為集群的一部分。
|