tomcat将404状态改成403进行http删除

Question

I'm having a weird issue where if my servlet sends a 200 ok http status, it works as intended, and the client gets a 200 status as expected. But, if my servlet returns a 404 status, tomcat seems to change it into a 403 status. This doesn't happen if I use the http get method. I haven't tested put or post .

I want to make it very clear that my servlets doDelete method gets executed just fine. It's just that the status code returned to the browser gets changed.

I'll provide a minimal testcase demonstrating the issue.

import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@WebServlet("/api/test403/*")
public class Test403 extends HttpServlet {
    public void doDelete(HttpServletRequest request, HttpServletResponse response) {
        try {
            String p = request.getParameter("send404");
            if (p != null && "1".equals(p)) {
                response.sendError(HttpServletResponse.SC_NOT_FOUND, "not found.");
            } else {
                response.sendError(HttpServletResponse.SC_OK, "ok.");
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
    private static final long serialVersionUID = 1L;
}

then i test via the following urls

myproject/api/test403?send404=1
myproject/api/test403?send404=0

What could cause this behavior? I'm not overly familiar the whole servlet/container architecture. I'm only experiencing this issue on 1 server which uses tomcat 7.0.41. I tried another server, which didn't exhibit this behavior.

edit - Per request, here's some output from the network panel in chrome. I used ajax to initiate this particular request:

Request Headers

DELETE /xxxxx HTTP/1.1
Host: xxxxx
Connection: keep-alive
Origin: xxx
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Accept: */*
Referer: xxx
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cookie: xxx

Response Headers

HTTP/1.1 403 Forbidden
Server: Apache-Coyote/1.1
Content-Type: application/json;charset=UTF-8
Transfer-Encoding: chunked
Content-Encoding: gzip
Vary: Accept-Encoding
Date: Wed, 16 Apr 2014 02:30:32 GMT

I didn't remove any headers, although I anonymized some values.

Answer 1

A combination of...

• an http DELETE request
• calling HttpServletResponse.sendError(status, message) to send the 404 from your servlets doDelete() method
• configuring a custom 404 error handler page(eg, via the <error-page> directive in web.xml )
• Keeping the default value of readonly = true for your context

will cause the client to receive a 403 status instead of the 404 you though you sent.

A request to a servlet can service an http delete request without needing readonly to be false, but a request to a file cannot. What happens is that when you call sendError() , tomcat will try to find a custom error page that matches up with whatever http status you specified. In this case, it found one ( /my404.html ), and so in order to process it, it basically restarts the entire request routing/dispatching process, including running all the filters on the request. But, this time, since it's a static file request, it comes across a built in filter that looks for http the DELETE method, and then checks if readonly = false . If it's not, the request is rejected, and it changes the response status to 403 forbidden because you're not allowed to delete the static file named /my404.html .

A sensible workaround is to use HttpServletResponse.setStatus(status) instead of HttpServletResponse.sendError(status, message) , so that tomcat doesn't try to find an error page. As mentioned by @BogdanZurac , you may also need to send a brief response body (ie, "oops Error 404") in addition to setting the status to prevent it from seeking the custom error page.