Subbu,
sorry but tomcat is not the reference implementation and I'm not that interested in copying them exactly on this sort of stuff.
The difference is not actually in sendError, both containers will preserve headers.
It is that jetty's default error handler set's the cache control assuming that errors are transient, so you don't cache a 404 or 500 and see that after the problem has been fixed.
Maybe on tomcat errors are more persistent so it's best to cache them 
But seriously, neither container is right/wrong. Both are entitled to generate error pages how they like. Jetty chooses to generate non cacheable error pages.
There is a standard mechanism to replace the default error page generation, so you can easily take control of error pages if you don't want to depend on container specific behaviour.
I could check to see if the cache-control was already set, but I have no way of telling if it was generated from code like:
try
{
response.setHeader("Cache-Control", "public;max-age=360000");
generatePageThatCanBeCached(response);
}
catch(Exception e)
{
response.sendError(404);
}
in this case, the cache control header is set, but actually applies
to the generated page and should not be applied to the error page.
Added setCacheControl to the error handler, so that you can now do
context.getErrorHandler().setCacheControl(null);
to turn off the default cache control.
If need be, we can create a context init parameter that defaultweb.xml can set to also control this. If that is desirable, reopen this issue.
regards