<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>That is certainly one interpretation. I just checked HTTPbis and the language for 501 is unchanged. Given its ambiguity, one would think it would have been clarified by now.<br><br><span style="background-color: rgba(255, 255, 255, 0);">Cheers,<br><br>Christopher Ferris<br>IBM Distinguished Engineer, CTO Industry and Cloud Standards<br>Member, IBM Academy of Technology<br>IBM Software Group, Standards Strategy<br>email: <a href="mailto:chrisfer@us.ibm.com" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="0">chrisfer@us.ibm.com</a><br>Twitter: christo4ferris<br>phone: <a href="tel:+1%20508%20234%202986" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="1">+1 508 234 2986</a></span></div><div><br>On Dec 6, 2012, at 7:46 AM, "Mark McLoughlin" <<a href="mailto:markmc@redhat.com">markmc@redhat.com</a>> wrote:<br><br></div><blockquote type="cite"><div>
<pre>On Thu, 2012-12-06 at 05:32 -0700, Christopher B Ferris wrote:
> Mark,
>
>
> The term "request method" in the HTTP spec refers exclusively to the
> tokens described in sect 5.1.1 Method (GET, PUT, POST, etc). Hence,
> 405 and 501 are inappropriate, because they refer to situations where
> the request method is not implemented, etc.
I understand that line of thinking, but as I said:
"I take the second sentence to be an example of one of cases where 501
is appropriate, rather than the only case"
i.e. the first sentence:
"The server does not support the functionality required to fulfill the
request"
doesn't mention request methods.
Cheers,
Mark.
> I should think that 400 is appropriate,accompanied with a suitable
> explanation (error message).
>
> Cheers,
>
> Christopher Ferris
> IBM Distinguished Engineer, CTO Industry and Cloud Standards
> Member, IBM Academy of Technology
> IBM Software Group, Standards Strategy
> email: <a href="mailto:chrisfer@us.ibm.com">chrisfer@us.ibm.com</a>
> Twitter: christo4ferris
> phone: +1 508 234 2986
>
> On Dec 6, 2012, at 7:06 AM, "Mark McLoughlin" <<a href="mailto:markmc@redhat.com">markmc@redhat.com</a>>
> wrote:
>
>
> > Hey,
> >
> > Kevin raised a good point here:
> >
> > <a href="https://review.openstack.org/17565">https://review.openstack.org/17565</a>
> >
> > Currently attempting to set a host's status to disabled will fail with
> > 400 Bad Request (without any explanatory error message) if you're using
> > the libvirt driver.
> >
> > To be clear, this is a PUT request containing a representation of the
> > desired status for the host and we don't support changing its status.
> >
> > I proposed changing this to return a 501 Not Implemented with an
> > explanatory message, but it's not clear that's correct either.
> >
> > Things to consider:
> >
> > - 4xx codes are for client errors - is this a client error? There is
> > no way for a client to know that a cloud supports this without
> > trying it, so it's obviously something we expect clients to do.
> >
> > - 400 explicitly states that clients should not retry the request
> > without modifications. That does apply here.
> >
> > - 405 Method Not Allowed is only appropriate where a request method
> > isn't allowed. We do support PUT requests on host resources, just
> > not this particular request.
> >
> > - 5xx codes "indicate cases in which the server is aware that it has
> > erred or is incapable of performing the request". The latter part
> > seems appropriate here.
> >
> > - The 501 docs say:
> >
> > The server does not support the functionality required to
> > fulfill the request. This is the appropriate response when the
> > server does not recognize the request method and is not capable
> > of supporting it for any resource.
> >
> > The first sentence makes it seem like 501 is a good fit here. I
> > take the second sentence to be an example of one of cases where 501
> > is appropriate, rather than the only case.
> >
> >
> > I think I'm still leaning towards 501. Any thoughts?
> >
> > Cheers,
> > Mark.
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
> >
</pre></div></blockquote></body></html>