1
votes

Currently, we are deploying an AngularJS webapp using a tomcat servlet. that uses a standard Web Application deployment descriptor, web.xml located in the WEB-INF directory. The webapp directly handles URL mapping and error codes internally, so we would not like to have 404 error code when a resource is not found (Specially REST resources).

We have been able to but being able to get rid of the error changing 404 to 200, stills this solution does not convince me 100%.

(Normal use of error-page)

<error-page>
<error-code>404</error-code>
<location>/404.html</location>
</error-page>

(Is this solution ok?)

<error-page>
<!--Every time 200 is used as error code we stray further from God's Light.-->
<error-code>200</error-code>
<location>/404.html</location>
</error-page>

Is this solution the most appropriate or there is something we are missing?

2
Are you using JAX-RS or is this a home grown REST application? - stdunbar
JAX-RS on the backend (Java Server) and AngularJS on the front-end using $http component. This web.xml mentioned on the front-end .war file. - LuCG

2 Answers

-1
votes

There are two ways to look at this. For JAX-RS you can "catch" the 404 and do what you want. Basically for a reasonably modern server (Wildfly, JBoss, Glassfish, etc.) you should be able to do something like:

import javax.ws.rs.NotFoundException;
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.Response;
import javax.ws.rs.ext.ExceptionMapper;
import javax.ws.rs.ext.Provider;

@Provider
public class NotFoundExceptionMapper implements ExceptionMapper<NotFoundException> {

    @Override
    public Response toResponse(NotFoundException exception) {

        return Response.status(Response.Status.OK)
                .entity("rest path not found" )
                .type(MediaType.TEXT_PLAIN_TYPE)
                .build();
    }
}

See this page for other Response.Status codes.

But I would argue strongly that, just as your web.xml comment indicates, this is the wrong way to do it. If I am building a front end and I call a bad URL I should get the 404 back. Maybe I shouldn't get a 301 (redirect) back like the web.xml would give you. But getting a 404 is a real error code and it should be treated as such.

I apologize that this is Angular 1 code but my code did something like:

var result = $http.post('http://some/url/goes/here');
result.success(function (data, status) {
    $scope.showForm = false;
    $state.go('somewhere_good');
});
result.error(function (data, status) {    
    if (status === 409) {
        // handle conflict error
    }
    if (status === 500) {
        // handle internal error
    }

    // etc.
});

In this way you could handle the 404 directly in the front end and not anger the coding gods.

-1
votes

The error codes were related to the first request, using a filter this 404 issue was solved. The following picture clarifies it better:

enter image description here The filter only works one time, because once the app is loaded, for this case no more requests are done with the servlet. After it is loaded into the client (5) it handles error code as a normal Angular app will do.