Hi Olivier, Please note, that JIRA [1] was raised to track issue with bindings using invalid selectors. The fix is scheduled for inclusion into 7.1. Please fill free to contribute a code for the fix.
As for returning 400 instead of 404 when exchange does not exist for a requested operation, you can raise an improvement JIRA for the issue. I do not feel strongly that 400 should be returned instead of 404. As exchange does not exist, the operation does not exist as well. Thus, returning 404 here does not look wrong to me. Kind Regards, Alex [1] https://issues.apache.org/jira/browse/QPID-7642 On Thu, 30 Aug 2018 at 10:02, VERMEULEN Olivier <olivier.vermeu...@murex.com> wrote: > > Hello Rob, > > Regarding the first scenario it just feels weird that a POST returns a 404 > NOT_FOUND... I think 400 would indeed make more sense. > I'll have a look at the last scenario as soon as I have some time. > > Thanks, > Olivier > > -----Original Message----- > From: Rob Godfrey <rob.j.godf...@gmail.com> > Sent: mercredi 29 août 2018 17:58 > To: users@qpid.apache.org > Subject: Re: [Broker-J] HTTP management > > On Wed, 29 Aug 2018 at 17:21, VERMEULEN Olivier <olivier.vermeu...@murex.com> > wrote: > > > Hello, > > > > While working with the Broker-J HTTP management I found some strange > > behaviors, especially while binding a queue to an exchange. > > > > * If the exchange does not exist the creation of the binding returns > > 404 where I would expect a 5XX > > > > I think 404 is reasonable here - the binding is data in the exchange object > - if the exchange does not exist then there is no resource to be modified. > The error here is certainly client side, error code 400 would also make sense. > > > > * If the queue does not exist the creation of the binding returns 422 > > where I would also expect a 5XX > > > > Again there hasn't been an internal server error, the client has just asked > for something that is not "correct". I think here it would probably be > better just to use error code 400 than 422. > > > > * If the "x-filter-jms-selector" has an incorrect value (for example > > "*") I get an HttpServerErrorException (and not a > > HttpClientErrorException like the other ones) and the binding is > > actually created even though this exception is raised... > > > > For the last one: > > POST > > http;//localhost:8080/api/latest/exchange/default/default/myTopic/bind > > { > > "destination":"myQueue", > > "bindingKey":"#", > > "arguments": { > > "x-filter-jms-selector":"*" > > } > > } > > > > OK - this is incorrect, the request is bad (because the filter is > malformed) and so it should return a 4xx error - again 400 is probably the > most appropriate. Also the binding should not be created. > > > > > > > If you confirm these are not expected I can try to fix them > > > > > If you want to provide a patch for the last one, which is definitely a bug, > that would be great - thanks > > -- Rob > > > > > Regards, > > Olivier > > > > ******************************* > > > > This e-mail contains information for the intended recipient only. It > > may contain proprietary material or confidential information. If you > > are not the intended recipient you are not authorised to distribute, > > copy or use this e-mail or any attachment to it. Murex cannot > > guarantee that it is virus free and accepts no responsibility for any > > loss or damage arising from its use. If you have received this e-mail > > in error please notify immediately the sender and delete the original > > email received, any attachments and all copies from your system. > > > ******************************* > > This e-mail contains information for the intended recipient only. It may > contain proprietary material or confidential information. If you are not the > intended recipient you are not authorised to distribute, copy or use this > e-mail or any attachment to it. Murex cannot guarantee that it is virus free > and accepts no responsibility for any loss or damage arising from its use. If > you have received this e-mail in error please notify immediately the sender > and delete the original email received, any attachments and all copies from > your system. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
