-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Leo,
On 6/26/15 10:38 AM, Leo Donahue wrote: > On Fri, Jun 26, 2015 at 1:42 AM, André Warnier <a...@ice-sa.com> > wrote: > >> >> I must admit that your question above was a bit difficult to >> follow, in terms of if/then/else/unless, particularly late at >> night. > > > Yes, you are right. Sorry about that. I was trying to walk the > line between saying too much and not enough and so it came out all > gibberish. > > >> And the last paragraph made me think that perhaps the Tomcat logo >> might lead you to personalise things a bit more than is really >> healthy. (Or else I want to have a look at that code, because the >> Tomcat developers must be even smarter that I thought). >> >> But if your question in the end boils down to : *must* a filter >> necessarily call the next filter/webapp in the chain, then the >> answer is in the Servlet Specification. E.g. Servlet Spec v 3.0 >> final, Chapt 6 Filtering, Section 6.2 Main concepts, item 4 : >> "The filter *may* invoke the next entity in the filter chain".. >> It even adds : "Alternatively, the filter chain can block the >> request by not making the call to invoke the next entity, leaving >> the filter responsible for filling out the response object." >> >> (What you need to do then still, is to insure that you do indeed >> generate a valid response, whether it's an error or not. That's >> maybe the point where different containers may react slightly >> differently.). >> > > If I use a return statement to break out of a filter, what should > happen? Will the next filter run? No. The Filter is responsible for calling the next filter in the chain. If you don't, the target servlet will never be called. > Shouldn't a return statement in a filter, especially one that > comes right after a sendError call, send the error and direct the > user to the page configured for such errors? Yes. > The scenario I'm working on is a web service. The web service has > three filters, in order they are: throttle filter, authentication > filter, logging filter. > > If a user is not authenticated, the following code "should" break > out of the filter chain and redirect the user to a custom 403. It > works nice on Tomcat. > > HttpServletResponse httpResponse = (HttpServletResponse) response; > > httpResponse.sendError(HttpServletResponse.HttpServletResponse.SC_FORB IDDEN); > > return; > > What I'm seeing on other containers is that I get a NPE where the > Service class is trying to do something with the authenticated > user, which is null. I realize this is not an "other containers" > forum, but I was just curious what the expected behaviour *should* > be. If you have other stuff going on -- like custom error pages -- you might find that more of your own code is running than you expect. See Konstantin's response. It's terse, but I think he's likely getting to the root of your problem. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVjXlRAAoJEBzwKT+lPKRYKbIP/1qu3FTeXTe/npc0b8V+A6rQ NQ25s9gd/d1araILYRPViDS56k7hFGHLO82OBuJ+LPAIK4fn0wWM3fSbIw8VRAac nksimpXVYIjW6d7Q5im1osoBO7WBJJBfRRa+RsjvtbxSaWaYbtxW08irdH7gKBud HsitX1w2s252NUFyt6G37sPMtXTlNMyMVPgXJTq8iwnR7BR/bzFw514E1zEd9AX+ 98+MNP90044KqHDy33zWnYPU3aGR54uw6H+BfSDst4lSGWyVPzpo054WKsQuQEFu zglgB97iC78RLUbA2VaGo3K4CTQioAXEo25wn4jw/ls1fCMpCxWJTCivHHVutwnp B7q8qPtBx1mrLr+orGmkAPuNoVyLOGOhbsVY4P50iCXWN8aIGzc0uBE9D4rv919f iQgHHMaJajEmjuLNoJM15Kj2bc/oUvSCWyOEXMZGQuVN8FOAs2SLoeyuHXAfhzum 9MAiMhK1g4s16CqNWYtkG3ePcvAthaNB8ZOI7nNjOxa8Hr4PuET/Ram1MoX23d4g EuENlsj6DaIo0CGAWZv5Il3j6G4jUkjGyQFYU7xZN3ilBppmZN3h2xx6ZOReXNFd iq7KHbjfQSLEyjuCIV02I/VOAwKqJnU30T8aAcx93ftFzUxg6ixZD1zfEUwMlhvg JUn7r/FNXThidonZbGg4 =P26m -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
