On Sep 28, 2010, at 10:42, Paul Berry <[email protected]> wrote: Ok, I think I see where you're going with this, Mathias. If we were implementing a fresh REST API from scratch, having fewer endpoints and supporting more methods and response codes would probably make sense. Unfortunately, our existing REST interface is built on the indirector, and the indirector (as currently implemented) doesn't support HEAD requests, POST requests, or response codes such as 410 (gone) and your proposed 499 (requested).
That's true, but at least the post requests probably need to be added anyway. As to the response codes, I think we can handle that either through version-specific behavior or really, I am not sure any of these responses would actually be sent to the puppet clients. I'm also concerned that incompatibilities may arise between new servers and old clients if we add new response codes, since I don't know how existing Puppet agents will react to the 410 and 499 response codes. In the interest of a speedy implementation, and in the interest of avoiding incompatibilities, I think we should stick with the original proposal to add a "certificate_status" endpoint. I agree with this plan, but Mathias's proposal should probably be opened as a fetter request to track it. On Fri, Sep 17, 2010 at 11:56 AM, Mathias Gug <[email protected]> wrote: > Hi, > > Excerpts from Paul Berry's message of Fri Sep 17 14:12:54 -0400 2010: > > I'm feeling unsettled about Mathias's proposal, for a couple of reasons: > > > > 1. It relies on some indirector features that we don't currently support > > (410 errors, head requests, post requests, more richly detailed http > error > > messages, richer support of "accept" headers, and find requests with no > > key). Granted, some of these features would be nice to add, but I'm not > > sure it makes sense to do them just so that we can make the REST API for > > cert signing take this form. > > > > I totally agree with you. I've outlined a proposal that may be > complicated to implement due to technical limitation of the current > puppet code. > > I've mainly approached that from an API perspective - not knowing much > about the implementation details. > > > 2. It puts a bigger burden than I would like to put on clients of the > REST > > API to understand how the certificate system works. In my original > > proposal, if a client wanted to know the status of a hostname, they > would > > issue a single request and get the status back in an intuitive format. > If > > we go with Mathias's suggestions, the client has to issue several related > > requests and synthesize the result. If the client gets this wrong, they > may > > falsely conclude that a certificate is valid when it isn't, and that > could > > lead to a lot of customer confusion. > > Well - I depends what you'd like to do with the state. For the example > above, asking if a certificate is valid is: > > 1. HEAD https://<master>/<environment>/certificate/<cert_name> > > 200 Ok --> means the certificate is valid > > Other possible status are: > > 404 Not found --> means the certificate doesn't exist > 410 Gone --> means the certificate is revoked. > > What could be added here is a custom status that says there is csr > waiting for <cert_name>: > > 499 Requested > > > By having a specific REST call to > > query the status of a cert (analogous to "puppet cert --verify") we make > > sure it is our code that is determining the validity, so we can be sure > to > > do it right. > > > > Right - I also pondered that issue. Now that I think of it the REST API > could modified as follow: > > > > <state> is one of: > > > - 'requested' if the host has sent the server a certificate request > > > but no certificate has been issued. > > > 1. Http request: > HEAD https://<master>/<environment>/certificate_request/<cert_name> > > Http response: > 200 OK > > With the addition that when the certificate has been issued (ie the csr > has been process) the Http status code should be "410 Gone": > > 1. Http request: > HEAD https:// > <master>/<environment>/certificate_request/<issued_cert_name> > > Http response: > 410 Gone > > > On Fri, Sep 17, 2010 at 10:35 AM, Luke Kanies <[email protected]> > wrote: > > > > > I like Mathias's proposal, and I think all it leaves to solve is > signing of > > > certs, right? > > > > > This is done by a POST request: > > 1. Http request: > POST https://<master>/<environment>/certificate/ > > <cert_name> > > > <<< Server side processing: generate the certificate >>> > > > Http response: > 201 OK > Location: https://<master>/<environment>/certificate/<cert_name> > > https://<master>/<environment>/certificate/<cert_name> > > A side effect of the POST request would be to mark the csr as processed > (thus being able to return 410 Gone instead of 200 OK). > > -- > Mathias Gug > Ubuntu Developer http://www.ubuntu.com > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<puppet-dev%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
