RE: [OT] Re: Filter behaviour
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-2508/#_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
> 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
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
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
RE: [OT] Re: Filter behaviour
For SOAP, you *MUST* send back 500 or 400 with your SOAP fault back.
[1] http://www.w3.org/TR/soap12-part2/#tabresstatereccodes
-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
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
Re: [OT] Re: Filter behaviour
Leo Donahue wrote:
On Sat, Jun 27, 2015 at 8:37 AM, Konstantin Kolinko
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.
Hi.
I think that you should not mix SOAP and HTTP. They are two different things.
For SOAP, HTTP is a /transport/, one among several possible. For example, you should be
able to send your SOAP request over email, and it should not make a fundamental difference
to your SOAP application.
An analogy would be :
You are planning to attend a concert in town, for which you have a ticket.
To get to the concert, you take a bus, for which you have a (return) ticket too.
However, it turns out that your bus ticket is invalid, so the conductor throws you off the
bus and you never even get to the concert.
Should you have had a valid bus ticket, you would have gotten to the concert, only to find
out that your concert ticket is invalid. So they would not let you in to the concert. But
because your bus return ticket is valid, you would still be able to take the bus back
home, because for the bus line, there is no error. And the bus conductor would not know,
and not care, that you have just been thrown out of the concert.
(The concert people did they own thing, by refusing you entry. But they should not be
able, or allowed, to confiscate your bus return ticket).
In other words, HTTP and SOAP are independent, and you should not use status codes of the
one to return errors of the other. It just happens in this case that you are using HTTP
as a transport for SOAP.
The HTTP protocol layer has its own access control, authentication and authorisation
mechanism. You have to pass those, before your SOAP request even gets to the SOAP-based
application (the "web service"). Similarly, HTTP has rather well-defined status codes,
which relate to the HTTP part of the business.
After passing through HTTP, it may well be that the SOAP application has its own AAA
constraints, that are different from the HTTP-level ones. If there is no error at the
HTTP level, but there is one at the SOAP level, then the SOAP interaction should return a
normal HTTP response 200 OK, but with a SOAP error embedded in the SOAP message, and the
calling application should be able to deal with those at their own SOAP level, and not be
confused as to whether it has been refused access b
