HTTP request resource

[coderanger]

As kitchen-inspec runs remotely (unlike busser-serverspec) any tests using an HTTP client (e.g. Net::HTTP) to test HTTP responses on localhost will no longer work. This should be reworked into some kind of http_request resource that works in both local and remote execution.

[coderanger]

This might be best handled via a new operation in train.

[chris-rock]

Hi @coderanger Thanks for bringing up this topic. We are thinking about this for a while, especially a way to capture the abstraction right. Current resources are expected to run on the specific machine that inspec targets. A http resource works remotely too. This may confuse users.

I would love to understand your usecase better. Could you share the way you use Net::HTTP currently?

[coderanger]

One of my simpler examples where I only use the response body: https://github.com/poise/poise-service/blob/master/test/integration/default/serverspec/mixin_spec.rb#L30

More complex examples including checking response status and a multi-stage get/post/get test: https://github.com/poise/application_examples/blob/master/test/integration/dpaste/serverspec/dpaste_spec.rb

The first seems pretty easy to model with train (via a new method on the transport), the latter might be a little more tricky since it needs to support POST as well.

[coderanger]

Overall the idea is being able to make a request against localhost no matter which mode inspec is running in. If remote, it should serialize the response and send to back over the transport with the body, status, and response headers.

[coderanger]

Spent some more time thinking about this last night. The cleanest solution is probably to run the locally with Net::HTTP for local, open an SSH tunnel for ssh (and then run locally as before), and to use powershell and then serialize the response for winrm. Not sure what would be best for the docker transport.

[chris-rock]

@coderanger Interesting use case. In your case you checked localhost only. Is your idea to verify that a service is up and running?

From an implementation point of view: In case we would allow to check http resources, we could start with offering a new resource for normal urls aka http('http://example.com') that provides all the features you need.

To implement localhost will be interesting. Since localhost is where inspec runs, this may not be the remote machine you targeted. I need to think about this further...

[legal90]

+1 for http resource.
We'd like to use it to verify different responses from HTTP server:
https://github.com/parallels-cookbooks/confluence/blob/7dc271ed/test/integration/helpers/serverspec/spec_helper.rb#L26-L45

Currently we have to use "serverspec" + "infrataster", which is not so convenient to install.

[chris-rock]

@legal90 For now I propose to write your own http resource and put it into an InSpec profile as documented here: https://github.com/chef/inspec/blob/master/docs/dsl_resource.rst

[coderanger]

This should be reopened as the new resource doesn't seem answer the same use case, specifically it looks like it runs the HTTP connection locally within InSpec and so cannot test local host connections.

[chris-rock]

@coderanger Thank you for bringing this up.

[chris-rock]

I close this in favor for the more detailed ticket #1436