x/crypto/acme: Unable to get rate limit periods in a reliable way

[calavera]

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

Go 1.8.0

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"

What did you do?

I'm using crypto/acme to create certificates from Let's Encrypt. The ACME spec provides a way to get rate limit information from providers in a reliable way:

https://tools.ietf.org/html/draft-ietf-acme-acme-05#section-6.4.1

However, crypto/acme doesn't provider any straightforward way to get those limits, leaving to everyone that uses it to implement the same logic over and over again to get those values:

An example of what people need to do every time they use crypto/acme:

client := &acme.Client{
  Key: pk, 
  DirectoryURL: "directoryURL",
}

authz, err := client.Authorize(context.Background(), "example.com")
if ae, ok := err.(*acme.Error); ok {
  r := ae.Header.Get("Retry-After")
  if r != "" {
    	i, err := strconv.ParseInt(r, 10, 64)
	if err != nil {
		// check if the header value is a time value and parse it properly
	}
        time.Sleep(time.Duration(i) * time.Second)
        // retry logic
  }
}

What did you expect to see?

I think these kind of checks are frequent enough that the library should provide a more straightforward way to get the limit time or duration, something like this:

client := &acme.Client{
  Key: pk, 
  DirectoryURL: "directoryURL",
}

authz, err := client.Authorize(context.Background(), "example.com")
if d, ok := acme.IsRateLimited(err); ok {
  time.Sleep(d)
  // retry logic
}

What did you see instead?

I created a small helper in my project to handle this. But that's something that every developer using crypto/acme will have to implement. I think it'd make sense to provide that logic by default with the library.

I also created a change request: https://go-review.googlesource.com/#/c/37463/

[gopherbot]

CL https://golang.org/cl/37463 mentions this issue.

[gopherbot]

CL https://golang.org/cl/38436 mentions this issue.