| Author |
Message
|
| ptimson |
 Posted: Tue Oct 20, 2015 5:12 am Post subject: Message Broker HTTP Web server 404 Failure Catch |
 |
|
Newbie
Joined: 20 Oct 2015
Posts: 5
|
I have the following HTTPInput nodes listening on my broker:
1: /my-app/v1/objectA/*
2: /my-app/v1/objectB/*
3: /my-app/v1/objectC/*
4: /my-app/v1/objectD/*
If a user trys to access an invalid object i.e.
Then the broker throws:
| Code: |
HTTP/1.1 404 Not Found
<html><head><title>IBM Integration Bus error report</title></head>
<body><h1>HTTP Status 404 - Resource Not Found</h1>
URI /my-app/v1/objectX does not map to any message flow in broker IB1<p>
<h3>IBM Integration Bus 9002</h3></body></html>
|
I want to catch this and throw a custom response i.e.
| Code: |
HTTP/1.1 404 Not Found
<error>My Custom Error</error> |
I tried creating an HTTPInput node that listen on the following:
However these seem to catch everything so if I enter /my-app/v1/objectA/1 I can’t hit the correct flow (above)
1 Option I know would be to be to have 1 HTTP Input Node /* or /my-app/v1/* and then manually route to subflows. However this is not a practical solution in this case and I want to create a failure catch.
Thanks for your advice! |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Oct 20, 2015 5:43 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You could build a flow that forwarded the incoming request via an HTTPRequest node.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| ptimson |
| Posted: Tue Oct 20, 2015 7:07 am Post subject: |
|
|
Newbie
Joined: 20 Oct 2015
Posts: 5
|
| mqjeff wrote: |
| You could build a flow that forwarded the incoming request via an HTTPRequest node. |
But surely the HTTP Request will be caught by the generic flow? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Oct 20, 2015 7:10 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| ptimson wrote: |
| mqjeff wrote: |
| You could build a flow that forwarded the incoming request via an HTTPRequest node. |
But surely the HTTP Request will be caught by the generic flow? |
Yes. And what is stopping that flow from using an HTTPRequest node?
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| ptimson |
| Posted: Wed Oct 21, 2015 3:21 am Post subject: |
|
|
Newbie
Joined: 20 Oct 2015
Posts: 5
|
| mqjeff wrote: |
| ptimson wrote: |
| mqjeff wrote: |
| You could build a flow that forwarded the incoming request via an HTTPRequest node. |
But surely the HTTP Request will be caught by the generic flow? |
Yes. And what is stopping that flow from using an HTTPRequest node? |
If I have two HTTPInput nodes listening on:
1: /my-app/v1/*
2: /my-app/v1/objectA/*
Request to: /my-app/v1/objectA/1
This will be caught by generic HTTPInput 1 and if we do a HTTPRequest to /my-app/v1/objectA/1 it will again get caught at HTTPInput 1 I will not be able to hit HTTPInput 2 |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Oct 21, 2015 3:53 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| ptimson wrote: |
If I have two HTTPInput nodes listening on:
1: /my-app/v1/*
2: /my-app/v1/objectA/*
Request to: /my-app/v1/objectA/1
This will be caught by generic HTTPInput 1 and if we do a HTTPRequest to /my-app/v1/objectA/1 it will again get caught at HTTPInput 1 I will not be able to hit HTTPInput 2 |
hmmm. I hadn't thought of that.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 21, 2015 4:07 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| hmmm. I hadn't thought of that. |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| joebuckeye |
| Posted: Wed Oct 21, 2015 4:07 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 365
Location: Columbus, OH
|
To do this you would need to change the URI for the non-generic ones to be something that wouldn't be caught by the generic flow.
/my-app/v1/objectA/* --> /private/v1/objectA/* |
|
| Back to top |
|
|
| ptimson |
| Posted: Wed Oct 21, 2015 5:52 am Post subject: |
|
|
Newbie
Joined: 20 Oct 2015
Posts: 5
|
| joebuckeye wrote: |
To do this you would need to change the URI for the non-generic ones to be something that wouldn't be caught by the generic flow.
/my-app/v1/objectA/* --> /private/v1/objectA/* |
Yes this would be a solution  I just wish there was a way of catching only the /my-app/v1/* that hadnt been defined  Dont really want to add an unnecessary HTTPRequest in |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Oct 21, 2015 6:10 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The HTTP request doesn't get as far as the message flow if the URL doesn't match.
You could put an HTTP server in front of IIB and use some kind of error handling there.
IIB gives you good tools for exporting your IIB http config into a config file for either WAS IHS or Apache.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| tdolby |
| Posted: Fri Oct 23, 2015 1:46 pm Post subject: |
|
|
Newbie
Joined: 29 Jun 2004
Posts: 8
|
The described behaviour looks defective, as it's hard to see how the /* node taking everything would be desirable . . .
It looks like the HTTP Input node accepts Java regular expression syntax in the toolkit, so if you put the string
into the "Path suffix for URL" field for the node, then it works like /* but avoids the problem described in the original post (at least in my experiments on v10). (The E and Q bits are needed to get around the escaping applied in the IIB code).
Worth trying the regular expression to try and get things going, and then raising a PMR for this if possible.
_________________
Trevor Dolby
IIB Development |
|
| Back to top |
|
|
| ptimson |
| Posted: Tue Oct 27, 2015 2:13 am Post subject: |
|
|
Newbie
Joined: 20 Oct 2015
Posts: 5
|
| tdolby wrote: |
The described behaviour looks defective, as it's hard to see how the /* node taking everything would be desirable . . .
It looks like the HTTP Input node accepts Java regular expression syntax in the toolkit, so if you put the string
into the "Path suffix for URL" field for the node, then it works like /* but avoids the problem described in the original post (at least in my experiments on v10). (The E and Q bits are needed to get around the escaping applied in the IIB code).
Worth trying the regular expression to try and get things going, and then raising a PMR for this if possible. |
This is exactly what I'm looking for. Seems to work in v9 Thanks @tdolby
Just one question why cant we use:
Cheers |
|
| Back to top |
|
|
| inMo |
| Posted: Tue Oct 27, 2015 4:52 am Post subject: |
|
|
Master
Joined: 27 Jun 2009
Posts: 216
Location: NY
|
| Quote: |
| ...it's hard to see how the /* node taking everything would be desirable . . . |
It is not desirable and forces workarounds and constraints. Will this make it into a list of fixes for future release without PMR?
Thanks for providing an alternate approach. It will go into the future use file. |
|
| Back to top |
|
|
| tdolby |
| Posted: Mon Nov 02, 2015 1:01 pm Post subject: |
|
|
Newbie
Joined: 29 Jun 2004
Posts: 8
|
There's no reason you can't use .* instead of .+ as long as it works - I think I instinctively stay off the / URL because traffic sprayers often poll on / (using "HEAD /") to see if a machine is up, and I'd rather not have that stuff hitting flows but that's probably just a holdover from when we didn't have autoRespondHTTPHEADRequests as an option.
To answer the other question: yes, we'd like to include this in a future product version (and hopefully backport to current releases), but no promises as to when this might happen . . .
_________________
Trevor Dolby
IIB Development |
|
| Back to top |
|
|
|
|
