Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Message-ID: <55915C68.1060605@ice-sa.com>
Date: Mon, 29 Jun 2015 16:55:36 +0200
From: =?UTF-8?B?QW5kcsOpIFdhcm5pZXI=?= <aw@ice-sa.com>
Reply-To: aw@ice-sa.com
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: [OT] Re: Filter behaviour
References: 
 <CA+EUcEPEKDX+k-Zc2Hi+0QYqGyQetXoGf3DBssas3RVjyeDH-A@mail.gmail.com>
 <CY1PR0501MB1612C4E073E63592D781BA2ACCAA0@CY1PR0501MB1612.namprd05.prod.outlook.com>
In-Reply-To: 
 <CY1PR0501MB1612C4E073E63592D781BA2ACCAA0@CY1PR0501MB1612.namprd05.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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:donahulf2@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.kolinko@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org