Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Response object should have TLS certificates begin/end dates to allow assertions N days before expiry #2498

AndiDog opened this issue Apr 14, 2022 · 1 comment
feature new-http issues that would require (or benefit from) a new HTTP API


Copy link

AndiDog commented Apr 14, 2022

Feature Description

Only these TLS-related fields are available right now:

// Response is a representation of an HTTP response
type Response struct {
	// ...
	Timings        ResponseTimings          `json:"timings"`
	TLSVersion     string                   `json:"tls_version"`
	TLSCipherSuite string                   `json:"tls_cipher_suite"`
	OCSP           netext.OCSP              `json:"ocsp"`
	// ...

If each X.509 certificate in the chain provided by the server could be represented there, k6 checks could assert that no certificate expires in the next N days.

Even better: if the client certificate for the request, if any is specified, is also represented, the whole request/response pair can be used in assertions.

Suggested Solution (optional)

No response

Already existing or connected issues / PRs (optional)

No response

Copy link

Hi @AndiDog , thanks for the feature request 🙇.

As I explained in #2391 (comment) adding more fields to the Response has its downsides. In that particular case it also added only one field out of one particular certificate. From what I gather you want the whole which I would argue is better. This still does mean that we will be creating and returning potentially many certificates object that will likely not be used by the majority of the users. But those users will still experience a performance degradation due to that.

Given that I would really prefer if this is done in the future new HTTP API where hopefully most of those issues will be solved from the grounds up. There has been some work started in actual experimentation around it so hopefully at least a PoC will be coming in the following few release cycles 🤞 .

Connected issues: #2393

@mstoykov mstoykov added the new-http issues that would require (or benefit from) a new HTTP API label Apr 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
feature new-http issues that would require (or benefit from) a new HTTP API
None yet

No branches or pull requests

2 participants