ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Message Broker HTTP Web server 404 Failure Catch

Post new topic  Reply to topic
 Message Broker HTTP Web server 404 Failure Catch « View previous topic :: View next topic » 
Author Message
ptimson
PostPosted: Tue Oct 20, 2015 5:12 am    Post subject: Message Broker HTTP Web server 404 Failure Catch Reply with quote

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.

    /my-app/v1/objectX


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:

    /*
    /my-app/v1/*


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
View user's profile Send private message
mqjeff
PostPosted: Tue Oct 20, 2015 5:43 am    Post subject: Reply with quote

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
View user's profile Send private message
ptimson
PostPosted: Tue Oct 20, 2015 7:07 am    Post subject: Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Tue Oct 20, 2015 7:10 am    Post subject: Reply with quote

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
View user's profile Send private message
ptimson
PostPosted: Wed Oct 21, 2015 3:21 am    Post subject: Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Wed Oct 21, 2015 3:53 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Wed Oct 21, 2015 4:07 am    Post subject: Reply with quote

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
View user's profile Send private message
joebuckeye
PostPosted: Wed Oct 21, 2015 4:07 am    Post subject: Reply with quote

Partisan

Joined: 24 Aug 2007
Posts: 364
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
View user's profile Send private message
ptimson
PostPosted: Wed Oct 21, 2015 5:52 am    Post subject: Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Wed Oct 21, 2015 6:10 am    Post subject: Reply with quote

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
View user's profile Send private message
tdolby
PostPosted: Fri Oct 23, 2015 1:46 pm    Post subject: Reply with quote

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
Code:
\E/.+\Q
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
View user's profile Send private message
ptimson
PostPosted: Tue Oct 27, 2015 2:13 am    Post subject: Reply with quote

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
Code:
\E/.+\Q
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:
Code:
\E/.*\Q


Cheers
Back to top
View user's profile Send private message
inMo
PostPosted: Tue Oct 27, 2015 4:52 am    Post subject: Reply with quote

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
View user's profile Send private message
tdolby
PostPosted: Mon Nov 02, 2015 1:01 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Message Broker HTTP Web server 404 Failure Catch
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.