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
[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: Filter behaviour
>>
>> > 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
>>
>
> Gentlemen,
>
> Thank you for the assistance.
>
> I still don't know what was causing my issue on said other container with
> respect to sendError and custom error-page elements, but...
>
> This works fine and was really what I was after, a simple custom 403
> message, no html:
>
> 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
> httpResponse.getOutputStream().print("blah, blah, blah");
>
> // return from the doFilter method
> return;
> }
>
> chain.doFilter(request, response);
>
> }
>
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Filter behaviour
On Fri, Jun 26, 2015 at 11:09 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Leo,
>
> >
> > 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
>
Gentlemen,
Thank you for the assistance.
I still don't know what was causing my issue on said other container with
respect to sendError and custom error-page elements, but...
This works fine and was really what I was after, a simple custom 403
message, no html:
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");
httpResponse.getOutputStream().print("blah, blah, blah");
// return from the doFilter method
return;
}
chain.doFilter(request, response);
}
leo
Re: Filter behaviour
-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 > 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
Re: Filter behaviour
2015-06-25 23:11 GMT+03:00 Leo Donahue :
> public void doFilter(ServletRequest request, ServletResponse response,
> FilterChain chain) throws IOException, ServletException
>
> Assuming you have only a single Filter configured in web.xml
>
> Assuming you have logic in a doFilter that checks the value of a boolean.
> If the boolean is true, then assume you send a http status code back and
> use a "return" in the if condition.
>
> example:
>
> if (someConditionIsTrue)
> {
> HttpServletResponse httpResponse = (HttpServletResponse)
> response;
> httpResponse.sendError(HttpServletResponse.WHATEVER_YOU_CHOOSE);
> return;
> }
>
> chain.doFilter(request, response);
>
>
> My question is:
>
> If the chain is placed inside an else, which would not run if the condition
> is true, does that violate the Filter in any way? In other words, if one
> does not call chain.doFilter within a doFilter method, should one expect
> something bad?
>
> What I'm really saying without saying it is, whether I call chain.doFilter
> in or out of an "else", on Tomcat I get the sendError status that I expect,
> but not from other containers. I realize that statement is moot on this
> list, but I thought I would share it.
>
> Are there any conditions in which Tomcat will decide what to do on its own,
> related to sendError, when it can't figure it out from code?
>
> Leo
>
>
> Using CATALINA_BASE: "C:\apache-tomcat\apache-tomcat-7.0.62"
> Using CATALINA_HOME: "C:\apache-tomcat\apache-tomcat-7.0.62"
> Using CATALINA_TMPDIR: "C:\apache-tomcat\apache-tomcat-7.0.62\temp"
> Using JRE_HOME:"C:\Program Files (x86)\Java\jdk1.7.0_67"
> Using CLASSPATH:
> "C:\apache-tomcat\apache-tomcat-7.0.62\bin\bootstrap.jar;C:\apache-tomcat\apache-tomcat-7.0.62\bin\tomcat-juli.jar"
> Server version: Apache Tomcat/7.0.62
> Server built: May 7 2015 17:14:55 UTC
> Server number: 7.0.62.0
> OS Name:Windows 7
> OS Version: 6.1
> Architecture: x86
> JVM Version:1.7.0_67-b01
> JVM Vendor: Oracle Corporation
1. A Filter can generate the response by itself. There is no need to
call the chain.
An example in Tomcat:
org.apache.catalina.filters.RemoteAddrFilter
org.apache.catalina.filters.RequestFilter#process(...)
2. There are several types of dispatch defined in Servlet specification.
See e.g. javax.servlet.DispatcherType enumeration.
Usually a Filter is configured to serve 'REQUEST' dispatches. Thus an
'ERROR' dispatch (triggered by sendError()) bypasses the filter.
Read about filters in the Servlet specification.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Filter behaviour
On Fri, Jun 26, 2015 at 1:42 AM, André Warnier 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? 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? 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_FORBIDDEN); 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. Leo
Re: Filter behaviour
Leo Donahue wrote:
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException
Assuming you have only a single Filter configured in web.xml
Assuming you have logic in a doFilter that checks the value of a boolean.
If the boolean is true, then assume you send a http status code back and
use a "return" in the if condition.
example:
if (someConditionIsTrue)
{
HttpServletResponse httpResponse = (HttpServletResponse)
response;
httpResponse.sendError(HttpServletResponse.WHATEVER_YOU_CHOOSE);
return;
}
chain.doFilter(request, response);
My question is:
If the chain is placed inside an else, which would not run if the condition
is true, does that violate the Filter in any way? In other words, if one
does not call chain.doFilter within a doFilter method, should one expect
something bad?
What I'm really saying without saying it is, whether I call chain.doFilter
in or out of an "else", on Tomcat I get the sendError status that I expect,
but not from other containers. I realize that statement is moot on this
list, but I thought I would share it.
Are there any conditions in which Tomcat will decide what to do on its own,
related to sendError, when it can't figure it out from code?
Leo
Using CATALINA_BASE: "C:\apache-tomcat\apache-tomcat-7.0.62"
Using CATALINA_HOME: "C:\apache-tomcat\apache-tomcat-7.0.62"
Using CATALINA_TMPDIR: "C:\apache-tomcat\apache-tomcat-7.0.62\temp"
Using JRE_HOME:"C:\Program Files (x86)\Java\jdk1.7.0_67"
Using CLASSPATH:
"C:\apache-tomcat\apache-tomcat-7.0.62\bin\bootstrap.jar;C:\apache-tomcat\apache-tomcat-7.0.62\bin\tomcat-juli.jar"
Server version: Apache Tomcat/7.0.62
Server built: May 7 2015 17:14:55 UTC
Server number: 7.0.62.0
OS Name:Windows 7
OS Version: 6.1
Architecture: x86
JVM Version:1.7.0_67-b01
JVM Vendor: Oracle Corporation
I must admit that your question above was a bit difficult to follow, in terms of
if/then/else/unless, particularly late at night. 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.).
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Filter behaviour
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException
Assuming you have only a single Filter configured in web.xml
Assuming you have logic in a doFilter that checks the value of a boolean.
If the boolean is true, then assume you send a http status code back and
use a "return" in the if condition.
example:
if (someConditionIsTrue)
{
HttpServletResponse httpResponse = (HttpServletResponse)
response;
httpResponse.sendError(HttpServletResponse.WHATEVER_YOU_CHOOSE);
return;
}
chain.doFilter(request, response);
My question is:
If the chain is placed inside an else, which would not run if the condition
is true, does that violate the Filter in any way? In other words, if one
does not call chain.doFilter within a doFilter method, should one expect
something bad?
What I'm really saying without saying it is, whether I call chain.doFilter
in or out of an "else", on Tomcat I get the sendError status that I expect,
but not from other containers. I realize that statement is moot on this
list, but I thought I would share it.
Are there any conditions in which Tomcat will decide what to do on its own,
related to sendError, when it can't figure it out from code?
Leo
Using CATALINA_BASE: "C:\apache-tomcat\apache-tomcat-7.0.62"
Using CATALINA_HOME: "C:\apache-tomcat\apache-tomcat-7.0.62"
Using CATALINA_TMPDIR: "C:\apache-tomcat\apache-tomcat-7.0.62\temp"
Using JRE_HOME:"C:\Program Files (x86)\Java\jdk1.7.0_67"
Using CLASSPATH:
"C:\apache-tomcat\apache-tomcat-7.0.62\bin\bootstrap.jar;C:\apache-tomcat\apache-tomcat-7.0.62\bin\tomcat-juli.jar"
Server version: Apache Tomcat/7.0.62
Server built: May 7 2015 17:14:55 UTC
Server number: 7.0.62.0
OS Name:Windows 7
OS Version: 6.1
Architecture: x86
JVM Version:1.7.0_67-b01
JVM Vendor: Oracle Corporation
Re: Filter behaviour ( settinf Content-Length header )
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jose,
On 2/27/14, 3:22 PM, Christopher Schultz wrote:
> Jose,
>
> On 2/27/14, 1:29 PM, Jose María Zaragoza wrote:
>> 2014-02-27 17:24 GMT+01:00 Konstantin Kolinko
>> :
>>> 2014-02-27 18:31 GMT+04:00 Jose María Zaragoza
>>> :
And what do you recommend to me for forcing to return a
Content-Type ? Some weird clients require it
If I cannot do it with a Filter , where can I do it ?
>>>
>>> You can do it in a Filter.
>>>
>>> As I said, 1. The header must be set before writing anything
>>> to the output stream. That is per HTTP/1.1 protocol. 2. The
>>> header must have correct value.
>>>
>>> How to implement that is up to you (do not expect me to teach
>>> you java programming, but maybe others here will do).
>>>
>>> If you do not know the length before response is generated, a
>>> solution can be to buffer the response before writing it out.
>>>
>>> Buffering can be done by writing an adapter around servlet
>>> response that replaces default output stream with a buffered
>>> one. The adapter can be implemented by extending
>>> javax.servlet.http.HttpServletResponseWrapper class. Some
>>> caching frameworks have filters that perform such buffering
>>> and caching.
>
>
>> Thanks. Finally, I did it with a servlet and it works
>
>> I tried with a Filter and a HttpServletResponseWrapper. Long time
>> before asking here. And I wrapped the response output stream
>> into a FilterOutputStream , so I could count every byte written I
>> got the right content length . All OK and I was happy. But , when
>> I tried set the header with wrapper.setHeader("Content-Length",
>> count ) , and as you told me before, the response headers had
>> already been flushed ( i checked isCommited() ) I could modify
>> output stream data but I couldn't modify response headers. I
>> don't understand but it is
>
> Don't forget that you actually need to buffer the data. You can't
> just wrap the container's OutputStream (or Writer) in a
> FilterOutputStream -- the bytes will flow through your stream
> (writer) back to the client while you are counting them.
>
> If you aren't using a big byte array (or something similar), then
> you aren't buffering.
You may be interested in this thread from 2009:
http://markmail.org/thread/fumpfuspt7a3nesz
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTD58JAAoJEBzwKT+lPKRYFeEP/RYqIt/69O/nBEI807rWvVKC
OGF2Cc41TwGpI2FG8H5BEvFUQNYBm3+Jjh7keN1kOdfvmKsGGpATFcVg3qnaDr22
qdT//2cUfARaCG3YrEyV02YTGH5aFuVPY9bM5qG4we2KSYwxeUlB150jWu/wRPLt
8VZnJmAuxUWkNqX0HnzT6P8k53npQhK7kT8Dj+pbHIfKfnJeU98BCUsDvbRHPCgJ
WRlDsEqzfOmSLM8pWKXv2NTu+cNcCf9mfEuNMyFFb35ySNnbq0Mo9ndCIRIUTKQL
jRhzLuKrpWDY+XnTADvT+IBkw6rSg9GWfchdfGi5m/RtNVpz09YdpFp4KcIPUdrb
okf4hPyCbdPGm1Rm0YDTiwxjZOtNjClnIQ+WEWuOxR49C1BYhAIclYNzJ87sWnwk
iQRteRTU+fcMLMvG1azS53jiiQsmndFIzQFJ53szIDmU8F08oybJG14IQI7nJP1l
wmQCf4yTTDKJijw1lO9z79mpi7CRaZr6vgPWV7y9+d/H9KyRXutjSafABG+iUB7I
9vTF+85AI0FX1OV5CA6te7eBqNrvwrzSreCSyXLuEJvqprhXtb+3XQApj8N3ml90
g6h7GfRnP8xwuiIs2MmMowoZ3JdtK44IjRkI/gKNwNvXlmKCSAM8m6tF5g32Bkuf
geCSTdZxgOTq/2NpUFfA
=XcJc
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Filter behaviour ( settinf Content-Length header )
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jose,
On 2/27/14, 1:29 PM, Jose María Zaragoza wrote:
> 2014-02-27 17:24 GMT+01:00 Konstantin Kolinko
> :
>> 2014-02-27 18:31 GMT+04:00 Jose María Zaragoza
>> :
>>>
>>> And what do you recommend to me for forcing to return a
>>> Content-Type ? Some weird clients require it
>>>
>>> If I cannot do it with a Filter , where can I do it ?
>>>
>>
>> You can do it in a Filter.
>>
>> As I said, 1. The header must be set before writing anything to
>> the output stream. That is per HTTP/1.1 protocol. 2. The header
>> must have correct value.
>>
>> How to implement that is up to you (do not expect me to teach you
>> java programming, but maybe others here will do).
>>
>> If you do not know the length before response is generated, a
>> solution can be to buffer the response before writing it out.
>>
>> Buffering can be done by writing an adapter around servlet
>> response that replaces default output stream with a buffered one.
>> The adapter can be implemented by extending
>> javax.servlet.http.HttpServletResponseWrapper class. Some
>> caching frameworks have filters that perform such buffering and
>> caching.
>
>
> Thanks. Finally, I did it with a servlet and it works
>
> I tried with a Filter and a HttpServletResponseWrapper. Long time
> before asking here. And I wrapped the response output stream into a
> FilterOutputStream , so I could count every byte written I got the
> right content length . All OK and I was happy. But , when I tried
> set the header with wrapper.setHeader("Content-Length", count ) ,
> and as you told me before, the response headers had already been
> flushed ( i checked isCommited() ) I could modify output stream
> data but I couldn't modify response headers. I don't understand but
> it is
Don't forget that you actually need to buffer the data. You can't just
wrap the container's OutputStream (or Writer) in a FilterOutputStream
- -- the bytes will flow through your stream (writer) back to the client
while you are counting them.
If you aren't using a big byte array (or something similar), then you
aren't buffering.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTD56OAAoJEBzwKT+lPKRYQ2EP/2FySYxzV177T3YB6Mf+7+ss
a9DGruZmfJ8EsD21qOO+qjnNOs7pc6sBHGjpCFRDzVut7hhAUzNJVXsVr/bUKzVg
fzrwFCEb+EDmE2fNdVjpDeP16HPOqzfBGwgSltNpYg40q0XXXwDdnZA8xDwUHwib
Iqdz7CJnZj6+5jiSMKOwFunEbC4d3U706/8AbgpUfScNQF9K+sNjwQfgEPQWtudb
IMF2n48Fm4MTfid+UQgQI5XGM9xFhLf+owPYTWyb+bO13ooLyCL8YFMBAKTSumfm
9HSojPOGz7cNOtUZjwIdCNtrcog6sZFoiAJ27Kxgs5qNPH8wMYkkrXMN28sI44A+
MG+8EICHcjRqP+e4Vb8wgb5jJwwK7Sqt5/DqFtNn/xv1m8ISCIe0pl9rgqYAfd5d
QtoNDhjW/V9aG+uhaYCHxEwSrVgscnuun04T49NK/Z4QsswerHmsDHSs79JXr8YW
iRjRj3GWpet5NTZ/k6WvO/5aw24uuk9OD+GMWpFAk3zmYOIh0CVE1WeVbHUXjUyo
mFZm4wxU3ccmQk2vqCoXqX5RVuaApMmc2M1wl+A5jzAqxwPWyBkPrQNg/k0SZ0/2
MSYG+qftA8sqF1v1Ydpb4U+hfNUXCKeatQY38rn43wXmEVkw/UOPtJQ8f3fAUFuL
7OHvXmOo/R3gE9cndILK
=pOC4
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Filter behaviour ( settinf Content-Length header )
2014-02-27 17:24 GMT+01:00 Konstantin Kolinko :
> 2014-02-27 18:31 GMT+04:00 Jose María Zaragoza :
>>
>> And what do you recommend to me for forcing to return a Content-Type ?
>> Some weird clients require it
>>
>> If I cannot do it with a Filter , where can I do it ?
>>
>
> You can do it in a Filter.
>
> As I said,
> 1. The header must be set before writing anything to the output
> stream. That is per HTTP/1.1 protocol.
> 2. The header must have correct value.
>
> How to implement that is up to you (do not expect me to teach you java
> programming, but maybe others here will do).
>
> If you do not know the length before response is generated, a solution
> can be to buffer the response before writing it out.
>
> Buffering can be done by writing an adapter around servlet response
> that replaces default output stream with a buffered one. The adapter
> can be implemented by extending
> javax.servlet.http.HttpServletResponseWrapper class. Some caching
> frameworks have filters that perform such buffering and caching.
Thanks.
Finally, I did it with a servlet and it works
I tried with a Filter and a HttpServletResponseWrapper. Long time
before asking here.
And I wrapped the response output stream into a FilterOutputStream ,
so I could count every byte written
I got the right content length . All OK and I was happy.
But , when I tried set the header with
wrapper.setHeader("Content-Length", count ) , and as you told me
before, the response headers had already been flushed ( i checked
isCommited() )
I could modify output stream data but I couldn't modify response
headers. I don't understand but it is
Regards
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Filter behaviour ( settinf Content-Length header )
2014-02-27 18:31 GMT+04:00 Jose María Zaragoza : > > And what do you recommend to me for forcing to return a Content-Type ? > Some weird clients require it > > If I cannot do it with a Filter , where can I do it ? > You can do it in a Filter. As I said, 1. The header must be set before writing anything to the output stream. That is per HTTP/1.1 protocol. 2. The header must have correct value. How to implement that is up to you (do not expect me to teach you java programming, but maybe others here will do). If you do not know the length before response is generated, a solution can be to buffer the response before writing it out. Buffering can be done by writing an adapter around servlet response that replaces default output stream with a buffered one. The adapter can be implemented by extending javax.servlet.http.HttpServletResponseWrapper class. Some caching frameworks have filters that perform such buffering and caching. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Filter behaviour ( settinf Content-Length header )
Did you try in the servlet?
2014-02-27 15:31 GMT+01:00 Jose María Zaragoza :
> Thanks
>
>
> And what do you recommend to me for forcing to return a Content-Type ?
> Some weird clients require it
>
> If I cannot do it with a Filter , where can I do it ?
>
> 2014-02-27 12:41 GMT+01:00 Konstantin Kolinko :
> > 2014-02-27 12:18 GMT+04:00 Jose María Zaragoza :
> >> Hello:
> >>
> >> I'm using Tomcat 6.0.24 and I'm testing how to return Content-Length
> header
> >> So I've defined a Filter and declared in web.xml of my web application
> >>
> >> If I do this:
> >>
> >> HttpServletResponse httpResponse = (HttpServletResponse) response;
> >> chain.doFilter(request, response);
> >> httpResponse.setHeader("Content-Length", "200");
> >>
> >> doesn't work ( it doesn't set the header and
> >> Transfer-Encoding:chunked is returned )
> >> )
> >>
> >> but
> >>
> >> HttpServletResponse httpResponse = (HttpServletResponse) response;
> >> httpResponse.setHeader("Content-Length", "200");
> >> chain.doFilter(request, response);
> >>
> >> does and it works OK
> >>
> >> Why ?
> >> Does anyone use a filter to set Content-Length header ?
> >> Must I declared in web.xml of Tomcat ?
> >>
> >>
> >
> > 1. Why are you using such an old build of 6.0.x?
> > 2. You cannot set headers when any part of the response has already
> > been sent to client. At that time headers have already been sent over
> > the wire.
> > See ServletResponse.isCommitted().
> > 3. You should be careful with that header. If you set it to a wrong
> > value you may break something.
> >
> > -
> > 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: Filter behaviour ( settinf Content-Length header )
Thanks
And what do you recommend to me for forcing to return a Content-Type ?
Some weird clients require it
If I cannot do it with a Filter , where can I do it ?
2014-02-27 12:41 GMT+01:00 Konstantin Kolinko :
> 2014-02-27 12:18 GMT+04:00 Jose María Zaragoza :
>> Hello:
>>
>> I'm using Tomcat 6.0.24 and I'm testing how to return Content-Length header
>> So I've defined a Filter and declared in web.xml of my web application
>>
>> If I do this:
>>
>> HttpServletResponse httpResponse = (HttpServletResponse) response;
>> chain.doFilter(request, response);
>> httpResponse.setHeader("Content-Length", "200");
>>
>> doesn't work ( it doesn't set the header and
>> Transfer-Encoding:chunked is returned )
>> )
>>
>> but
>>
>> HttpServletResponse httpResponse = (HttpServletResponse) response;
>> httpResponse.setHeader("Content-Length", "200");
>> chain.doFilter(request, response);
>>
>> does and it works OK
>>
>> Why ?
>> Does anyone use a filter to set Content-Length header ?
>> Must I declared in web.xml of Tomcat ?
>>
>>
>
> 1. Why are you using such an old build of 6.0.x?
> 2. You cannot set headers when any part of the response has already
> been sent to client. At that time headers have already been sent over
> the wire.
> See ServletResponse.isCommitted().
> 3. You should be careful with that header. If you set it to a wrong
> value you may break something.
>
> -
> 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: Filter behaviour ( settinf Content-Length header )
2014-02-27 12:18 GMT+04:00 Jose María Zaragoza :
> Hello:
>
> I'm using Tomcat 6.0.24 and I'm testing how to return Content-Length header
> So I've defined a Filter and declared in web.xml of my web application
>
> If I do this:
>
> HttpServletResponse httpResponse = (HttpServletResponse) response;
> chain.doFilter(request, response);
> httpResponse.setHeader("Content-Length", "200");
>
> doesn't work ( it doesn't set the header and
> Transfer-Encoding:chunked is returned )
> )
>
> but
>
> HttpServletResponse httpResponse = (HttpServletResponse) response;
> httpResponse.setHeader("Content-Length", "200");
> chain.doFilter(request, response);
>
> does and it works OK
>
> Why ?
> Does anyone use a filter to set Content-Length header ?
> Must I declared in web.xml of Tomcat ?
>
>
1. Why are you using such an old build of 6.0.x?
2. You cannot set headers when any part of the response has already
been sent to client. At that time headers have already been sent over
the wire.
See ServletResponse.isCommitted().
3. You should be careful with that header. If you set it to a wrong
value you may break something.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
[Ticket #603] Filter behaviour ( settinf Content-Length header )
This is a notification from the Help Desk.
Ticket closed by Sudhindra Rao.
On Feb 27, 2014 @ 02:16 pm, Sudhindra Rao wrote:
Ticket closed.
==Ticket History==
On Feb 27, 2014 @ 02:10 pm, it Support wrote:
Assigned to Sudhindra Rao.
--
On Feb 27, 2014 @ 01:43 pm, demablo...@gmail.com wrote:
Hello:
I'm using Tomcat 6.0.24 and I'm testing how to return Content-Length header
So I've defined a Filter and declared in web.xml of my web application
If I do this:
HttpServletResponse httpResponse = (HttpServletResponse) response;
chain.doFilter(request, response);
httpResponse.setHeader("Content-Length", "200");
doesn't work ( it doesn't set the header and
Transfer-Encoding:chunked is returned )
)
but
HttpServletResponse httpResponse = (HttpServletResponse) response;
httpResponse.setHeader("Content-Length", "200");
chain.doFilter(request, response);
does and it works OK
Why ?
Does anyone use a filter to set Content-Length header ?
Must I declared in web.xml of Tomcat ?
Regards
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
--
This is an automated response. Your issue has been noted. We'll be in touch
soon.
Please reply to this email or visit the URL below with any additional details.
http://swithelp.innoviti.com/portal/view-help-request/603
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
[Ticket #603] Filter behaviour ( settinf Content-Length header )
This is a notification from the Help Desk.
Ticket was assigned to Sudhindra Rao.
On Feb 27, 2014 @ 02:10 pm, it Support wrote:
Assigned to Sudhindra Rao.
==Ticket History==
On Feb 27, 2014 @ 01:43 pm, demablo...@gmail.com wrote:
Hello:
I'm using Tomcat 6.0.24 and I'm testing how to return Content-Length header
So I've defined a Filter and declared in web.xml of my web application
If I do this:
HttpServletResponse httpResponse = (HttpServletResponse) response;
chain.doFilter(request, response);
httpResponse.setHeader("Content-Length", "200");
doesn't work ( it doesn't set the header and
Transfer-Encoding:chunked is returned )
)
but
HttpServletResponse httpResponse = (HttpServletResponse) response;
httpResponse.setHeader("Content-Length", "200");
chain.doFilter(request, response);
does and it works OK
Why ?
Does anyone use a filter to set Content-Length header ?
Must I declared in web.xml of Tomcat ?
Regards
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
--
This is an automated response. Your issue has been noted. We'll be in touch
soon.
Please reply to this email or visit the URL below with any additional details.
http://swithelp.innoviti.com/portal/view-help-request/603
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Filter behaviour ( settinf Content-Length header )
Hello:
I'm using Tomcat 6.0.24 and I'm testing how to return Content-Length header
So I've defined a Filter and declared in web.xml of my web application
If I do this:
HttpServletResponse httpResponse = (HttpServletResponse) response;
chain.doFilter(request, response);
httpResponse.setHeader("Content-Length", "200");
doesn't work ( it doesn't set the header and
Transfer-Encoding:chunked is returned )
)
but
HttpServletResponse httpResponse = (HttpServletResponse) response;
httpResponse.setHeader("Content-Length", "200");
chain.doFilter(request, response);
does and it works OK
Why ?
Does anyone use a filter to set Content-Length header ?
Must I declared in web.xml of Tomcat ?
Regards
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat filter behaviour
2012/5/29 Alexander Landsnes Keül : > So my expectations contain the only bugs in this instance :) > > Thanks. I suspected it might be something like that, but I hadn't seen > anything about it. Now to work around the issue, we've been rather dependent > on how it worked in the past but I believe I understand why it had to change. > I added mention of conf/web.xml processing changes to the Migration Guide, http://tomcat.apache.org/migration-7.html Best regards, Konstantin Kolinko > 2012/5/29 Alexander Landsnes Keül : >> I'm seeing some behaviour from Tomcat 7 that I'd classify as "funky" when it >> comes to servlet filters. First off the technical setup >>(...) >> - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat filter behaviour
So my expectations contain the only bugs in this instance :) Thanks. I suspected it might be something like that, but I hadn't seen anything about it. Now to work around the issue, we've been rather dependent on how it worked in the past but I believe I understand why it had to change. Alex -Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: 29. mai 2012 16:10 To: Tomcat Users List Subject: Re: Tomcat filter behaviour 2012/5/29 Alexander Landsnes Keül : > I'm seeing some behaviour from Tomcat 7 that I'd classify as "funky" when it > comes to servlet filters. First off the technical setup > > JDK 1.7.0_03 (64-bit) > Tomcat 7.0.26 (64-bit) binaries > 4 instances of Tomcat share those binaries, each installed as a pretty > standard windows service using service.bat. Their bin folder contains the > required files, tomcat-juli.jar and a setenv.bat as well as a renamed > tomcat7w.exe for convenience. > > The setup itself works like a charm, I can run webapps on all the above > servers and they all have their own ports for the connector, shutdown and > ajp. I also double checked that no application references catalina.home for > config, they all check catalina.base. > The problem appears when I try to use the Waffle servlet filter to > authenticate a remote user on one of the above instances. I ran it in a few > different scenarios, and the behavior leaves me puzzled. All the scenarios > run with the filter logging turned on, so it appears to behave correctly. > > 1) > I defined the and elements in the (shared) web.xml > for a tomcat instance, with /*. I tried having it > both at the very start, and the very end of the file with the exact same > behaviour. The filter would only work correctly on the very root of the > tomcat server, so http://localhost:8180/. Attempting to navigate to any other > context would appear to trigger the Kerberos auth (HTTP headers contained > Authorization: Negotiate & what I believe is a Base64 encoded Kerberos > ticket), but the the remote user retrieved from the servlet would be null. > > 2) > I moved the config from the shared web.xml and over to a specific webapp that > needs the remote user. This works like a charm, more or less as expected. > without SSO. > > 3) > Moving the filter definition, but not the filter-mapping, to the shared > web.xml, and then mapping it in a context specific web.xml also works as > expected. The remote user can be retrieved from the servlet. > > The second setup, having Waffle defined in the context specific web.xml, > won't be an option for us in a production environment. Ideally the same war > file should be deployable to an environment with SSO and also without SSO. It > could be solved by two versions of the web.xml, but it's more of a last > resort. > We've got a similar setup, on an old Tomcat 6.0.26 test instance, where > waffle runs like a charm from the shared web.xml. A major difference here > being that catalina.base & catalina.home refer to the exact same folder. > > Is this behaviour intended? That a filter-mapping in the shared web.xml is > disregarded in the contexts? Or am I seeing a bug of sorts here? I'll admit > to my knowledge of the servlet spec is cursory at best, but this strikes me > as wrong. I've got a virtual server I can fiddle with if anyone has > suggestions as to how I can "fix" this behaviour. > Yes, it is intended behaviour and Tomcat 7 here differs from earlier versions. See explanation here: https://issues.apache.org/bugzilla/show_bug.cgi?id=51754#c1 You may also want to look at https://issues.apache.org/bugzilla/show_bug.cgi?id=52138#c4 Best regards, Konstantin Kolinko - 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: Tomcat filter behaviour
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexander, On 5/29/12 10:00 AM, Alexander Landsnes Keül wrote: > 2) I moved the config from the shared web.xml and over to a > specific webapp that needs the remote user. This works like a > charm, more or less as expected. without SSO. So, both and in WEB-INF/web.xml do not work with SSO, right? This is probably going to come down to the ordering of operations that are required to make both SSO and Waffle work properly. Perhaps the Waffle integration needs to be implemented as a Valve and not as a Filter? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/E4s8ACgkQ9CaO5/Lv0PD6igCaAmQxWFskqj8RxOMqfu5UqLeX azgAoLZbjW3pz0M2VqkqCZX4YfGPwYOP =Dezz -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat filter behaviour
There was a copy-paste artifact on my first mail that made no sense at the end of 2). Otherwise this is identical to my previous mail. I'm seeing some behaviour from Tomcat 7 that I'd classify as "funky" when it comes to servlet filters. First off the technical setup JDK 1.7.0_03 (64-bit) Tomcat 7.0.26 (64-bit) binaries 4 instances of Tomcat share those binaries, each installed as a pretty standard windows service using service.bat. Their bin folder contains the required files, tomcat-juli.jar and a setenv.bat as well as a renamed tomcat7w.exe for convenience. The setup itself works like a charm, I can run webapps on all the above servers and they all have their own ports for the connector, shutdown and ajp. I also double checked that no application references catalina.home for config, they all check catalina.base. The problem appears when I try to use the Waffle servlet filter to authenticate a remote user on one of the above instances. I ran it in a few different scenarios, and the behavior leaves me puzzled. All the scenarios run with the filter logging turned on, so it appears to behave correctly. 1) I defined the and elements in the (shared) web.xml for a tomcat instance, with /*. I tried having it both at the very start, and the very end of the file with the exact same behaviour. The filter would only work correctly on the very root of the tomcat server, so http://localhost:8180/. Attempting to navigate to any other context would appear to trigger the Kerberos auth (HTTP headers contained Authorization: Negotiate & what I believe is a Base64 encoded Kerberos ticket), but the the remote user retrieved from the servlet would be null. 2) I moved the config from the shared web.xml and over to a specific webapp that needs the remote user. This works like a charm, more or less as expected the remote user can be retrieved from the servlet. 3) Moving the filter definition, but not the filter-mapping, to the shared web.xml, and then mapping it in a context specific web.xml also works as expected. The remote user can be retrieved from the servlet. The second setup, having Waffle defined in the context specific web.xml, won't be an option for us in a production environment. Ideally the same war file should be deployable to an environment with SSO and also without SSO. It could be solved by two versions of the web.xml, but it's more of a last resort. We've got a similar setup, on an old Tomcat 6.0.26 test instance, where waffle runs like a charm from the shared web.xml. A major difference here being that catalina.base & catalina.home refer to the exact same folder. Is this behaviour intended? That a filter-mapping in the shared web.xml is disregarded in the contexts? Or am I seeing a bug of sorts here? I'll admit to my knowledge of the servlet spec is cursory at best, but this strikes me as wrong. I've got a virtual server I can fiddle with if anyone has suggestions as to how I can "fix" this behaviour. Alex - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat filter behaviour
2012/5/29 Alexander Landsnes Keül : > I'm seeing some behaviour from Tomcat 7 that I'd classify as "funky" when it > comes to servlet filters. First off the technical setup > > JDK 1.7.0_03 (64-bit) > Tomcat 7.0.26 (64-bit) binaries > 4 instances of Tomcat share those binaries, each installed as a pretty > standard windows service using service.bat. Their bin folder contains the > required files, tomcat-juli.jar and a setenv.bat as well as a renamed > tomcat7w.exe for convenience. > > The setup itself works like a charm, I can run webapps on all the above > servers and they all have their own ports for the connector, shutdown and > ajp. I also double checked that no application references catalina.home for > config, they all check catalina.base. > The problem appears when I try to use the Waffle servlet filter to > authenticate a remote user on one of the above instances. I ran it in a few > different scenarios, and the behavior leaves me puzzled. All the scenarios > run with the filter logging turned on, so it appears to behave correctly. > > 1) > I defined the and elements in the (shared) web.xml > for a tomcat instance, with /*. I tried having it > both at the very start, and the very end of the file with the exact same > behaviour. The filter would only work correctly on the very root of the > tomcat server, so http://localhost:8180/. Attempting to navigate to any other > context would appear to trigger the Kerberos auth (HTTP headers contained > Authorization: Negotiate & what I believe is a Base64 encoded Kerberos > ticket), but the the remote user retrieved from the servlet would be null. > > 2) > I moved the config from the shared web.xml and over to a specific webapp that > needs the remote user. This works like a charm, more or less as expected. > without SSO. > > 3) > Moving the filter definition, but not the filter-mapping, to the shared > web.xml, and then mapping it in a context specific web.xml also works as > expected. The remote user can be retrieved from the servlet. > > The second setup, having Waffle defined in the context specific web.xml, > won't be an option for us in a production environment. Ideally the same war > file should be deployable to an environment with SSO and also without SSO. It > could be solved by two versions of the web.xml, but it's more of a last > resort. > We've got a similar setup, on an old Tomcat 6.0.26 test instance, where > waffle runs like a charm from the shared web.xml. A major difference here > being that catalina.base & catalina.home refer to the exact same folder. > > Is this behaviour intended? That a filter-mapping in the shared web.xml is > disregarded in the contexts? Or am I seeing a bug of sorts here? I'll admit > to my knowledge of the servlet spec is cursory at best, but this strikes me > as wrong. I've got a virtual server I can fiddle with if anyone has > suggestions as to how I can "fix" this behaviour. > Yes, it is intended behaviour and Tomcat 7 here differs from earlier versions. See explanation here: https://issues.apache.org/bugzilla/show_bug.cgi?id=51754#c1 You may also want to look at https://issues.apache.org/bugzilla/show_bug.cgi?id=52138#c4 Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat filter behaviour
I'm seeing some behaviour from Tomcat 7 that I'd classify as "funky" when it comes to servlet filters. First off the technical setup JDK 1.7.0_03 (64-bit) Tomcat 7.0.26 (64-bit) binaries 4 instances of Tomcat share those binaries, each installed as a pretty standard windows service using service.bat. Their bin folder contains the required files, tomcat-juli.jar and a setenv.bat as well as a renamed tomcat7w.exe for convenience. The setup itself works like a charm, I can run webapps on all the above servers and they all have their own ports for the connector, shutdown and ajp. I also double checked that no application references catalina.home for config, they all check catalina.base. The problem appears when I try to use the Waffle servlet filter to authenticate a remote user on one of the above instances. I ran it in a few different scenarios, and the behavior leaves me puzzled. All the scenarios run with the filter logging turned on, so it appears to behave correctly. 1) I defined the and elements in the (shared) web.xml for a tomcat instance, with /*. I tried having it both at the very start, and the very end of the file with the exact same behaviour. The filter would only work correctly on the very root of the tomcat server, so http://localhost:8180/. Attempting to navigate to any other context would appear to trigger the Kerberos auth (HTTP headers contained Authorization: Negotiate & what I believe is a Base64 encoded Kerberos ticket), but the the remote user retrieved from the servlet would be null. 2) I moved the config from the shared web.xml and over to a specific webapp that needs the remote user. This works like a charm, more or less as expected. without SSO. 3) Moving the filter definition, but not the filter-mapping, to the shared web.xml, and then mapping it in a context specific web.xml also works as expected. The remote user can be retrieved from the servlet. The second setup, having Waffle defined in the context specific web.xml, won't be an option for us in a production environment. Ideally the same war file should be deployable to an environment with SSO and also without SSO. It could be solved by two versions of the web.xml, but it's more of a last resort. We've got a similar setup, on an old Tomcat 6.0.26 test instance, where waffle runs like a charm from the shared web.xml. A major difference here being that catalina.base & catalina.home refer to the exact same folder. Is this behaviour intended? That a filter-mapping in the shared web.xml is disregarded in the contexts? Or am I seeing a bug of sorts here? I'll admit to my knowledge of the servlet spec is cursory at best, but this strikes me as wrong. I've got a virtual server I can fiddle with if anyone has suggestions as to how I can "fix" this behaviour. Alex - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
