You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by J Lopez <jl...@gmail.com> on 2015/10/20 00:13:08 UTC

httpd 2.2 +mod-jk1.2.37+ tomcat 7.0.28 (debian package)

Hi all,

  is it possible to filter 404 application errors taking into account
content-type beside http return code in jk configuration.
  I need to difference between application is not deployed/executing (http
404 content-type html) and application running and returning a 404 json
response (content-type json)

  I have put mod-jk in debug mode and content-type is showed in logs. I
have not seen in documentation if a fail_on_status can be combined with
content-type returned.

  right now
my worker.properties

worker.list=clusterapp

# template
worker.template.port=8009
worker.template.type=ajp13
# En fail-over cuenta 1 prepost + 2 (intentos) connect
worker.template.prepost_timeout=10000
worker.template.connect_timeout=5000
worker.template.reply_timeout=20000
worker.template.socket_connect_timeout=10000
worker.template.connection_pool_timeout=600
# El interface REST devuelve 404 en el resto el 404 es error
worker.template.fail_on_status=503
# ------------------------
# First tomcat server
# ------------------------
worker.node1.reference=worker.template
worker.node1.host=tomcat01.fqdn
# ------------------------
# Second tomcat server
# ------------------------
worker.node2.reference=worker.template
worker.node2.host=tomcat02.fqdn
# ------------------------
# Load Balancer worker
# ------------------------
# Worker para el cluster jboss de produccion
worker.clusterapp.type=lb
worker.clusterapp.balanced_workers=node1,node2
worker.clusterapp.sticky_session=true

my uriwrokermap.properties file is:

# rest not fail over with 404
/app/rest/*=clusterapp

/app/*=clusterapp;fail_on_status=404


Thanks in advance for any help.

-- 
Saludos.

Re: httpd 2.2 +mod-jk1.2.37+ tomcat 7.0.28 (debian package)

Posted by Christopher Schultz <ch...@christopherschultz.net>.
J,

On 10/19/15 6:13 PM, J Lopez wrote:
>   is it possible to filter 404 application errors taking into account
> content-type beside http return code in jk configuration.
>   I need to difference between application is not deployed/executing (http
> 404 content-type html) and application running and returning a 404 json
> response (content-type json)

You want to handle this on the httpd-side or the Tomcat side?

> I have put mod-jk in debug mode and content-type is showed in logs. I
> have not seen in documentation if a fail_on_status can be combined with
> content-type returned.

One way to do this is to have a do-nothing ROOT application that has a
custom 404 error page that sets a different status: even something
that's very unusual. So the order of events would go like this:

GET /myapp/some/page - not found -> application returns 404 to httpd

GET /unknown/page - not found -> ROOT catches 404, returns 505 to httpd

Does that help?

-chris

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


Re: httpd 2.2 +mod-jk1.2.37+ tomcat 7.0.28 (debian package)

Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
On 21.10.2015 19:47, André Warnier (tomcat) wrote:
> On 20.10.2015 00:13, J Lopez wrote:
>> Hi all,
>>
>>    is it possible to filter 404 application errors taking into account
>> content-type beside http return code in jk configuration.
>>    I need to difference between application is not deployed/executing (http
>> 404 content-type html) and application running and returning a 404 json
>> response (content-type json)
>>
>>    I have put mod-jk in debug mode and content-type is showed in logs. I
>> have not seen in documentation if a fail_on_status can be combined with
>> content-type returned.
>>
> [...]
>
> I have not seen this in the documentation either, and it does not look like this feature
> is available.
>
> But if I understand correctly, you have 2 cases of 404 :
>
> 1) if the application is for Tomcat "not there" (meaning for example it is not deployed at
> that particular moment), then Tomcat itself returns a 404.
> 2) if the application is there and working, in some cases it returns a 404 itself.
>
> And for some reason, you want to distinguish these 2 cases.
>
> (It would help to know why, and at what level you want to distinguish this)
>
> But let's suppose that the application is normally installed at (tomcat)/webapps/app1, and
> responds to URLs like "/app1/*".
>
> If the "/webapps/app1" application is not there, then Tomcat will try to map this to the
> default application, "/webapps/ROOT/app1/*".  Then it will probably not find it there
> either, and return a 404 response.
>
> If the application is there, then Tomcat will (succesfully) map the call to
> /webapps/app1/*", and the application will respond. And, maybe, it will sometimes respond
> with a 404.
>
> So two possible solutions :
> 1) change the application, so that in such a case, it responds with something else than 404.
> 2) install something in /ROOT, which will catch everything that gets there, and respond
> with something else than 404.
> That supposes of course that you do not previously have a default application under
> /webapps/ROOT.
>


Addendum :
The above suggests a (possible) way to do this at the Tomcat level.
But you also mention "mod_jk", which implies that you have Apache httpd acting as a 
front-end to Tomcat and this application.

You could also do this at the Apache httpd level.
For Apache httpd, mod_jk (and all that is behind it, but that Apache httpd does not know 
or care about) is seen as the "application", which generates the HTTP response.
To filter such a response and possibly modify it before it goes back to the client, you 
would have to use an "output filter" at the Apache httpd level.
Start from here : http://httpd.apache.org/docs/2.2/filter.html

But again, you did not really indicate the level at which you need this, or for what 
ultimate purpose, so it is not easy to recommend a "better" solution.



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


Re: httpd 2.2 +mod-jk1.2.37+ tomcat 7.0.28 (debian package)

Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
On 20.10.2015 00:13, J Lopez wrote:
> Hi all,
>
>    is it possible to filter 404 application errors taking into account
> content-type beside http return code in jk configuration.
>    I need to difference between application is not deployed/executing (http
> 404 content-type html) and application running and returning a 404 json
> response (content-type json)
>
>    I have put mod-jk in debug mode and content-type is showed in logs. I
> have not seen in documentation if a fail_on_status can be combined with
> content-type returned.
>
[...]

I have not seen this in the documentation either, and it does not look like this feature 
is available.

But if I understand correctly, you have 2 cases of 404 :

1) if the application is for Tomcat "not there" (meaning for example it is not deployed at 
that particular moment), then Tomcat itself returns a 404.
2) if the application is there and working, in some cases it returns a 404 itself.

And for some reason, you want to distinguish these 2 cases.

(It would help to know why, and at what level you want to distinguish this)

But let's suppose that the application is normally installed at (tomcat)/webapps/app1, and 
responds to URLs like "/app1/*".

If the "/webapps/app1" application is not there, then Tomcat will try to map this to the 
default application, "/webapps/ROOT/app1/*".  Then it will probably not find it there 
either, and return a 404 response.

If the application is there, then Tomcat will (succesfully) map the call to 
/webapps/app1/*", and the application will respond. And, maybe, it will sometimes respond 
with a 404.

So two possible solutions :
1) change the application, so that in such a case, it responds with something else than 404.
2) install something in /ROOT, which will catch everything that gets there, and respond 
with something else than 404.
That supposes of course that you do not previously have a default application under 
/webapps/ROOT.




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