This is an IBM Automation portal for Integration products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
Idea Review. As part of our policy for regularly reassessing aged ideas we have recently discussed this enhancement request again and note that there was an APAR put in to both v10 and v11 for a setting on the JVM to remove detail from the reply message: https://www.ibm.com/support/pages/apar/IT27097 Given this possibility seems to meet the initial use case we are closing the idea as delivered. If there is a greater nuance to the requirement which you feel remains unresolved or needs to be considered then feel free to open a new idea.
RFE Review. Thank you for raising this RFE and apologies it has remained in Submitted status for quite a while. In general we feel that a 405 Method Not Allowed is a more useful return status code than a 404, if the URL is defined in IIB/ACE but with different operations. In theory you could argue that returning a 405 tells the caller that the URL exists, which in some very strict quarters could be interpreted as a security exposure. It would be possible for us to add a (non-default) server wide option which means that a 404 would be returned rather than the 405 for the benefit of those that feel this is a concern. The other wider debate which is brought up in the RFE is that some users may prefer to change the body content of the error and avoid BIP messages in the 404. This aspect of the RFE could be covered by the user nominating a "flow of last resort" containing an HTTP Input node inside it which essentially acts as an error handler for all un-assigned URL paths. Defining this as a flow rather than asking the user for configuration which defines the content of the message would be greater flexibility for the user to choose any message domain (json/xml/blob etc) for the response, and furnish it further with more detailed behaviours using the power of the whole array of the flow palette. We would be interested in the community's view of both these aspects of the RFE and will continue to monitor. Status updated to Uncommitted Candidate.