Skip to content

TASK-5830: TLSRPT #791

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

TASK-5830: TLSRPT #791

wants to merge 3 commits into from

Conversation

juliebin
Copy link
Contributor

@juliebin juliebin commented May 8, 2025

  • Give your PR a recognizable title. For example: "FE-123: Add new prop to component" or "Resolve Issue Create new-pricing-increases-costs #123: Fix bug in component"
  • Your PR title will be visible in changelogs

What Changed

  • What changes does this PR propose?
  • Provide screenshots or screen recordings for any visual changes.

How To Test or Verify

  • Describe any steps that may help reviewers verify changes.
  • Anything beyond basic unit testing, such as assistive tech usage, or special interactions.

PR Checklist

Below are some checklists to follow for the correct procedure in different circumstance. The first list ("All PRs Checklist") should be followed for ALL PRs. The next 2 are additive to this list depending on what type of PR you are using.

For example: If you are submitting a content change to one of the support documents, your checklist would include the:

  • "All PRs Checklist"
  • AND the "Content Changes Checklist

If you are submitting a feature addition, enhancement, or bug fix, your checklist would include the:

  • "All PRs Checklist"
  • AND the "Development Changes Checklist"

All PRs Checklist

  • Give your pull request a meaningful name.
  • Use lowercase filenames.
  • Apply at least one team label according to which team is the content expert (ie. team-FE or team-SAZ)
  • Pull request approval from the FE team or content experts (see label applied above) that isn't the content creator.

Content Changes Checklist

  • Check that your article looks correct in the preview here or in a Netlify deploy preview.
  • Check the links in your article.
  • Check the images in your article (if there are any)
  • Check to make sure you are using markdown appropriately as outlined in examples/article.md in the root of the project directory and on the momentum doc's preface article
  • Check to make sure the Copy and Tone Guidelines are followed.

Development Changes Checklist (some checks are automatic github actions and will not be listed here. ie. "all tests pass")

  • The appropriate tests are created in cypress/ directory in the root of the project
  • The lighthouse score is passing according to the FE Support Docs' Service Outline SLI/SLOs

Copy link

netlify bot commented May 8, 2025

Deploy Preview for support-docs ready!

Name Link
🔨 Latest commit 4ae4dff
🔍 Latest deploy log https://app.netlify.com/sites/support-docs/deploys/681cdb4dcc9c290008dce729
😎 Deploy Preview https://deploy-preview-791--support-docs.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

in the RFC: https://datatracker.ietf.org/doc/html/rfc8460.

The following JSON fields are not defined in the RFC:
* `epoch` - timestamp in epoch of when the hook is invoked
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(nit) wording seems a little awkward. Maybe "epoch time" or "UNIX epoch"?


The following JSON fields are not defined in the RFC:
* `epoch` - timestamp in epoch of when the hook is invoked
* `type` - whether the data is for a successful TLS connection or a failure.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why 'type' rather than maybe 'status' or 'success'?

The following JSON fields are not defined in the RFC:
* `epoch` - timestamp in epoch of when the hook is invoked
* `type` - whether the data is for a successful TLS connection or a failure.
`0` - failure; `1` - success
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI, these end up on the same line in the preview.

Comment on lines +87 to +88
This hook returns `int`, but for now the return value has no significance, i.e. it is not checked in
the caller.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd drop the "i.e. ..." clause.

Comment on lines +92 to +93
This hook could be called in any thread. Please avoid to do time consuming tasks in the hook's
implementation.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest "... avoid doing time ..."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants