qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lorenz Quack <quack.lor...@gmail.com>
Subject Re: AW: potential java broker REST API bug
Date Mon, 07 Mar 2016 09:30:46 GMT
Hi Julien,

As I alluded to in my other eMail, PUT can be used for both creation and 
The specification [1] has the following to say:

"The PUT method requests that the state of the target resource be 
created or replaced with the state defined by the representation 
enclosed in the request message payload."


"If the target resource does not have a current representation and the 
PUT successfully creates one, then the origin server MUST inform the 
user agent by sending a 201 (Created) response. If the target resource 
does have a current representation and that representation is 
successfully modified in accordance with the state of the enclosed 
representation, then the origin server MUST send either a 200 (OK) or a 
204 (No Content) response to indicate successful completion of the request."

So I believe we do follow the spec and returning 4xx would violate it.

Kind regards,

[1] https://tools.ietf.org/html/rfc7231#section-4.3.4

On 07/03/16 08:39, Julien Charon wrote:
> Sorry I'm wrong regarding PUT.
> When the queue does not exist and is created, the broker returns HTTP status 201 and
an HTTP header "Location" is set in the response.
> If the queue already exists, the broker return HTTP status 200 and the "Location" header
is not set. So there is a way to determine if the queue already existed or not.
> However, in my opinion some 4XX code would be better.
> Best regards,
> Julien
> Avitech GmbH
> Engineering AxL
> Tel.: +49 (0)7541/282-177
> Fax: +49 (0)7541/282-199
> e-mail: julien.charon@avitech.aero
> ________________________________________________
> Avitech GmbH
> Principal Office: Bahnhofplatz 1 | 88045 Friedrichshafen | Germany
> Court Registration: Amtsgericht Ulm | HRB 728293
> Geschäftsführer/Managing Director: Jon Joseba Goyarzu Caño
> http://avitech.aero
> This message may contain confidential information and is intended only for the individual
named. If you are not the named addressee you should not disseminate, distribute or copy this
e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system.
> -----Ursprüngliche Nachricht-----
> Von: Rob Godfrey [mailto:rob.j.godfrey@gmail.com]
> Gesendet: Montag, 7. März 2016 09:14
> An: users@qpid.apache.org
> Betreff: Re: potential java broker REST API bug
> On 7 March 2016 at 07:06, Julien Charon <Julien.Charon@avitech.aero> wrote:
>> Indeed, copy paste error on this, sorry. I observed the behaviour not
>> only for DELETE, but also for PUT.
>> I.e. if I try to create a new queue and use a name of a queue that
>> already exists, e.g. "newQueue", the response sent will have HTTP
>> status 200 and no body content.
>> This means a client has no chance to find out that the queue already
>> existed and was not newly created.
>> So, if queue "newQueue" already existed, let's say configured as not
>> durable and the client sends a PUT request to create queue "newQueue"
>> configured as durable, the not durable queue "newQueue" will just
>> continue to exist. The client can only be aware of this if either the
>> broker is restarted and the queue will have disappeared or by checking
>> the configuration of the queue after having created it.
> I agree if the PUT to create an entity which is not identical on all attributes, then
it should cause an error.  If the object that would be created is identical, then I think
200 is correct.
> -- Rob
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org

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

View raw message