replace response code 403 with 404 in websphere

"https://mywebsite.com/contextroot/basic.html"

the above url is working fine because my project has basic.html under the "deployedResources/webapp"

but when i enter the url as "https://mywebsite.com/contextroot/basic.html/"

i am getting 403 forbidden , here i have added "/" to the url.

how to make the server to replace the response code "403 forbidden" with "404 page not found" when some add "/" to the url

we use websphere, jsp and servlets in our project

Solution

For this scenario in WebSphere the web container sends the 403 response code using the HttpServetResponse.sendError(int, String) method. As a result you can modify the response code using a filter and an HttpServletResponseWrapper. The Filter replaces the response object with your HttpServletResponseWrapper which then overrides the sendError methods. For example this HttpServletResponseWrapper:

package wrappers;

import java.io.IOException;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpServletResponseWrapper;

public class SendErrorResponseWrapper extends HttpServletResponseWrapper {

    HttpServletRequest _request;
    HttpServletResponse _wrappedResponse;

    public SendErrorResponseWrapper(HttpServletRequest request, HttpServletResponse response) {

        super(response);

        _request= request;
        _wrappedResponse= response;
    }

    @Override
    public void sendError(intstatus) throwsIOException {

        String path = _request.getServletPath() + _request.getPathInfo();

        if(status == 403 && path.endsWith("html/")) {
            _wrappedResponse.sendError(404);
        } else{
            _wrappedResponse.sendError(status);
        }
    }

    @Override
    public void sendError(intstatus, String msg) throwsIOException {

        String path = _request.getServletPath() + _request.getPathInfo();

        if(status == 403 && path.endsWith("html/")) {
            _wrappedResponse.sendError(404, msg);
        } else{
            _wrappedResponse.sendError(status, msg);
        }
    }

}

It added to request processing by this filter:

package filter;

import java.io.IOException;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.annotation.WebFilter;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import wrappers.SendErrorResponseWrapper;

@WebFilter(urlPatterns = "/*")
public class SendErrorFilter implements Filter {

    @Override
    public void destroy() {
    }

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {

        SendErrorResponseWrapper responseWrapper = new SendErrorResponseWrapper((HttpServletRequest) request, (HttpServletResponse) response);

        chain.doFilter(request, responseWrapper);
    }

    @Override
    public void init(FilterConfig arg0) throws ServletException {

    }

}

Notes:

The filter urlPatterm has to be /* to make sure it is called for the bad request. If the pattern was .html the filter would not be called for the bad request and “.html/“ is not valid urlPattern.

The response wrapper overrides the sendError methods and changes a 403 response code to 404 if the request was for a resource with ends with “html/“, otherwise leaves it as is. However a test for “html\” is somewhat simplistic because you may need this to work for other static file types or for other similar scenarios in which the webcontainer will return 403 for a static file request. Basically you get a 403 for a static file request in these conditions:

path contains “..” but does not start “/…”
path ends with “\”, “.” or “/“

However the difficulty for the filter is to make sure it does not change the response code, for example, for a request for a servlet where the path ends with “/“ because such a request would be valid. As a result, testing simply for a request path which ends with “/“ is too general and the test must be set with an understanding of what static resources the application intends to make available.