<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 11, 2017 at 12:06 PM Attila Fazekas <<a href="mailto:afazekas@redhat.com">afazekas@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi all,<br><br>Long time ago it was discussed to make the keystone HEAD responses<br> right [1] as the RFC [2][3] recommends:<br><br>"  A response to the HEAD method is identical to what an equivalent<br>   request made with a GET would have been, except it lacks a body. "<br><br></div><div>So, the status code needs to be identical as well !<br></div><div><br>Recently  turned out, keystone is still not correct in all cases [4].<br><br>'Get role inference rule' (GET), 'Confirm role inference rule' (HEAD)<br> has the same URL pattern, but they differs in the status code (200/204)<br> which is not allowed! [5]<br><br>This is the only documented case where both the HEAD and GET defined and<br>the HEAD has a 204 response.<br><br>Are you going to fix this [4] as it was fixed before [6] ? <br><br></div><div><div></div><div>Best Regards,<br></div><div>Attila<br><br></div><div>PS.: <br> Here is the tempest change for accepting the right code [7].</div></div></div></blockquote><div> </div><div>On Tempest side, adding a new accepted code into the test would open the doors to an API backward incompatible change on keystone side.</div><div>It should be possible for tests (as for a real application) to discover what kind of behaviour is available on server side, the 204 or the 200 response.</div><div>Otherwise any existing code that expects a 204 response will cease to work against clouds running a new version of keystone with the code change in.</div><div>If keystone would use a micro-version for this, Tempest would cap the existing test to a max micro-version, and develop a new test for the new behaviour.<br></div><div><br></div><div>andrea</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><br>[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-July/039140.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2014-July/039140.html</a><br>[2] <a href="https://tools.ietf.org/html/rfc7231#section-4.3.2" target="_blank">https://tools.ietf.org/html/rfc7231#section-4.3.2</a><br>[3] <a href="https://tools.ietf.org/html/rfc7234#section-4.3.5" target="_blank">https://tools.ietf.org/html/rfc7234#section-4.3.5</a><br>[4] <a href="https://bugs.launchpad.net/keystone/+bug/1701541" target="_blank">https://bugs.launchpad.net/keystone/+bug/1701541</a><br>[5] <a href="https://developer.openstack.org/api-ref/identity/v3/?expanded=confirm-role-inference-rule-detail,get-role-inference-rule-detail" target="_blank">https://developer.openstack.org/api-ref/identity/v3/?expanded=confirm-role-inference-rule-detail,get-role-inference-rule-detail</a><br>[6] <a href="https://bugs.launchpad.net/keystone/+bug/1334368" target="_blank">https://bugs.launchpad.net/keystone/+bug/1334368</a><br>[7] <a href="https://review.openstack.org/#/c/479286/" target="_blank">https://review.openstack.org/#/c/479286/</a></div></div></div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div>