Fix (APAR):  PI67942

Status:  Fix

Release:  8.5.5.10

Operating System:  AIX,HP-UX,IBM i,Linux,OS X,Solaris,Windows,z/OS

Supersedes Fixes:  

CMVC Defect:  xxxxxx

Byte size of APAR:  422322

Date: 2016-09-26

Abstract:  javax.servlet.httpservletrequest.getrequesturi() might return a decoded value after dispatching

Description/symptom of problem:  
PI67942 resolves the following problem:

ERROR DESCRIPTION:                                              
Invoking HttpServletRequest.getRequestURI() returns a decoded   
URI if it is invoked after dispatching the request when a       
decoded path was passed to                                      
javax.servlet.ServletRequest.getRequestDispatcher(String        
path).                                                          

LOCAL FIX:                                                      

PROBLEM SUMMARY

USERS AFFECTED:
 IBM WebSphere Application Server versions
8.5.5 and 9.0, and Websphere Application
Server Liberty users of Web Container.

PROBLEM DESCRIPTION:
Invoking
HttpServletRequest.getRequestURI()
after dispatching the request
incorrectly returns a decoded URI if a
decoded path was passed to
javax.servlet.ServletRequest.getRequest
Dispatcher() or
javax.servlet.AsyncContext.dispatch()

RECOMMENDATION:
None

If a decoded path is used when invoking
ServletRequest.getRequestDispatcher() or one of the
AsyncContext.dispatch() methods,
HttpServletRequest.getRequestURI() returns a decoded URI
instead of an encoded URI after the request has been
dispatched.
The following is an example of this problem:
ServletA:
...
request.getRequestDispatcher("/ServletB/a b").forward();
...
ServletB:
...
String uri = request.getRequestURI();
...
The "uri" variable in ServletB will have the following value:
/ServletB/a b
The getRequestURI() method should return an URL encoded value.

PROBLEM CONCLUSION:                                             
The WebContainer has been modified to return a decoded URI      
when invoking HttpServletRequest.getRequestURI() after          
dispatching.                                                    
                                                                
A new context parameter needs to be set to true in the          
application's web.xml to enable this fix. If this fix is        
enabled, the developer must make sure that any invocations to   
ServletRequest.getRequestDispatcher() and                       
AsyncContext.dispatch() are being done using decoded paths as   
a parameter:                                                    
                                                                
<context-param>                                                 
                                                                
<param-name>com.ibm.ws.webcontainer.ENCODE_DISPATCHED_REQUEST_UR
I</param-name>                                                  
        <param-value>true</param-value>                         
</context-param>                                                
                                                                
After enabling the fix the "uri" variable in the example above  
will have the following value:                                  
                                                                
/ServletB/a%20b                                                 
                                                                
If an encoded path is used when invoking                        
ServletRequest.getRequestDispatcher() and                       
AsyncContext.dispatch() when this fix is enabled the "uri"      
variable will have the following value:                         
                                                                
/ServletB/a%2520b                                               
                                                                
This will be considered an application error and can be fixed   
by using decoded paths when invoking                            
ServletRequest.getRequestDispatcher() and                       
AsyncContext.dispatch().                                        
                                                                
The fix for this APAR is currently targeted for inclusion in    
fix packs 8.5.5.11, 9.0.0.2 and 16.0.0.3. Please refer to the   
recommended updates page for delivery information:              
                                                                
http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980   


Directions to apply fix:  Fix applies to Editions:
Release 8.5
_X_ Application Server (Express or BASE)
_X_ Network Deployment (ND)
__ Liberty Core
__ Edge Components
__ Developer

Install Fix to all WebSphere installations unless special instructions are included below.

Special Instructions: None

NOTE:
The user must:
* Logged in with the same authority level when unpacking a fix, fix pack or refresh pack.
* Be at V1.4.3 or newer of the Installation Manager. Certain iFixes may require a newer version of the Installation Manager and the Installation Manager will inform you during the installation process if a newer version is required.

The IBM Knowledge Center can provide details, if needed, on the use of the Installation Manager to apply the iFixes.
http://publib.boulder.ibm.com/infocenter/install/v1r4/index.jsp.  Shutdown WebSphere Application Server before applying the iFixes.  Restart WebSphere Application Server after applying the iFixes.

Directions to remove fix:  

The IBM Knowledge Center can provide details, if needed, on the use of the Installation Manager to remove the iFixes.
http://publib.boulder.ibm.com/infocenter/install/v1r4/index.jsp.  Shutdown WebSphere Application Server before removing the iFixes.  Restart WebSphere Application Server after removing the iFixes.

Directions to re-apply fix:  
1) Shutdown WebSphere Application Server.

2) Follow the Fix instructions to apply the fix.

3) Restart WebSphere Application Server.



Additional Information: