Yeah, you're right. I don't see *MUST* in my reference either. They *must* /pun intended/ have dropped the language for SOAP 1.2. A little vague, with this table, though the table implicitly states that it *MUST* be 400 or 500 since there is no other code that and it is a complete table.
I said *MUST* because SOAP 1.1 explicitly states it [1]: "In case of a SOAP error while processing the request, the SOAP HTTP server MUST issue an HTTP 500 "Internal Server Error" response and include a SOAP message in the response containing a SOAP Fault element (see section 4.4) indicating the SOAP processing error." George [1] http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383529 -----Original Message----- From: André Warnier [mailto:a...@ice-sa.com] Sent: Monday, June 29, 2015 8:56 AM To: Tomcat Users List Subject: Re: [OT] Re: Filter behaviour George Stanchev wrote: > For SOAP, you *MUST* send back 500 or 400 with your SOAP fault back. > > [1] http://www.w3.org/TR/soap12-part2/#tabresstatereccodes Not to start a fight on SOAP on this Tomcat forum, but in the wording of the section referenced above, I definitely do not see that you *MUST* send a 5xx or 4xx Status Code back. One should start reading a bit earlier, at "7.5.2.2 Receiving". The gist seems to be : send a 2xx code back, along with a SOAP envelope containing the SOAP fault, or if you cannot, then use one of the HTTP error codes below. But sending /only/ a HTTP error code is, in my view, confusing for the client, because it would not be able to distinguish between a HTTP transport error, and a service-level error. > > -----Original Message----- > From: Leo Donahue [mailto:donahu...@gmail.com] > Sent: Saturday, June 27, 2015 11:45 PM > To: Tomcat Users List > Subject: [OT] Re: Filter behaviour > > On Sat, Jun 27, 2015 at 8:37 AM, Konstantin Kolinko <knst.koli...@gmail.com> > wrote: > >>> public void doFilter(ServletRequest request, ServletResponse >> response, >>> FilterChain chain) throws IOException, ServletException >>> { >>> boolean iAmNotAuthorized = true; >>> >>> if (iAmNotAuthorized) >>> { >>> // generate the HTTP Servlet Response for a 403 status code >>> HttpServletResponse httpResponse = (HttpServletResponse) >>> response; >>> //httpResponse.sendError(HttpServletResponse.SC_FORBIDDEN); >>> httpResponse.setStatus(HttpServletResponse.SC_FORBIDDEN); >>> httpResponse.setHeader("WWW-Authenticate", "Basic"); >> "WWW-Authenticate" header is usually used with 401 response. >> >> It is unusual to use it with 403 one, though the spec does not forbid >> it. (I am not sure how browsers react here, though) >> >> http://tools.ietf.org/html/rfc7235#section-4.1 >> >> >> Best regards, >> Konstantin Kolinko >> >> > http://tools.ietf.org/html/rfc7231#section-6.5.3 > > And we "may" send a 404 to hide the existence of a forbidden target. It's > misleading. That seems to open the door for any kind of response, or no > response. > > I am on the fence about sending 401 or 403 responses from a web service. > They both indicate "something is there, you just can't get to it". > > The 401 alludes that something is wrong with your username/password. > > The 403 is more vague. You "may" have the right username and password (and > I'm not going to bother to tell you), but your account "may" not have the > correct role associated with using this service, so rather than say anymore, > I'll just let you know you are forbidden. Users have no idea, other than > there is something good at the end of this request for me to be forbidden. > > From the perspective of troubleshooting customer requests to your published > web service, developers can log the unsuccessful attempt (Authentication or > Authorization) and review the log files for answers to trouble shooting, but > sending back a status code doesn't seem to always make sense depending on > what types of application clients your customers are using. > > For example: > > Suppose you call a SOAP web service that takes an object as a parameter and > that service returns another type of object. When customers expect an > object, they may get a HTTP status code of 401 or 403 if they botched sending > the correct username/password in the authentication header. And maybe, their > password is merely expired. In situations like those, it seems more > reasonable to send back a Soap Fault of some kind as defined in the schema. > The message could be as simple as: Authorization failed. > > It seems easier for clients to know that a soap web service may throw a > ClientAuthorizationException for example, rather than parse out a HTTP status > code response? > > I don't know though. > > Leo > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
