HTTP status 204 is an error?

[megrxu]

I found that 204 status and 301 redirect will be regarded as errors. But 204 is widely used to check the connectivity, for example http://connectivity-check.ubuntu.com. The workaround is to use TCP but not the HTTP. But I still think it's not proper to disallow 204 or 301.

[rrjanbiah]

@megrxu

Basically you've to use up_status and must_contain https://github.com/sourcegraph/checkup/blob/master/check/http/http.go#L28

In this page https://tryingtobeawesome.com/checkup/ they've provided some notes.

Note that you can also use exec checker which is not seem to be released for the public yet.

[titpetric]

@rrjanbiah I'd welcome some exec checker examples from your side if you're already written any scripts for custom checks. Mostly interested in what kind of checks people may be writing. Apart from "ping".

[titpetric]

@megrxu to stay on topic:

Do you have an example of a service where you can't match against an specified HTTP status code? You can match against any code you like, but only 1 code at once. Checkup makes the assumption that you control the endpoint and expect only one code which is correct for your case.

There are some variants of breaking changes that might be possible:

• a configuration addition for UpStates ([]int) - not breaking, opt-in,
• a checker change to accept 2XX if you don't define an UpState explicitly

I think it's relatively safe to implement the second type of check, which doesn't cover 301 response as valid. There's always going to be a check against the HTTP Status code, along with any content checks (must_contain, must_not_contain) - so even if you don't set up state explicitly, skipping HTTP Status response checks is a non-starter.

I'm also not super sure that we want to allow 2XX:

StatusOK                   = 200 // RFC 7231, 6.3.1
StatusCreated              = 201 // RFC 7231, 6.3.2
StatusAccepted             = 202 // RFC 7231, 6.3.3
StatusNonAuthoritativeInfo = 203 // RFC 7231, 6.3.4
StatusNoContent            = 204 // RFC 7231, 6.3.5
StatusResetContent         = 205 // RFC 7231, 6.3.6
StatusPartialContent       = 206 // RFC 7233, 4.1
StatusMultiStatus          = 207 // RFC 4918, 11.1
StatusAlreadyReported      = 208 // RFC 5842, 7.1
StatusIMUsed               = 226 // RFC 3229, 10.4.1

Out of these, there are a few which I'd consider invalid, so, 200-204 (inclusive)?

[rrjanbiah]

@rrjanbiah I'd welcome some exec checker examples from your side if you're already written any scripts for custom checks. Mostly interested in what kind of checks people may be writing. Apart from "ping".

@titpetric Here's the one:

{
  "type": "exec",
  "name": "Testing if PostgreSQL is up or down",
  "command": "pg_isready", // https://www.postgresql.org/docs/9.3/app-pg-isready.html
  "arguments": "-h localhost -p 5432"
//  "must_contain": "accepting connections" // NOT required, as return value will be non-zero
}

[megrxu]

@titpetric

• a checker change to accept 2XX if you don't define an UpState explicitly

I think this could be a great solution. As you said, accepting all 2xx is not a good idea.