Bump github.com/sandrolain/httpcache from 1.4.0 to 1.4.2

[dependabot]

Bumps github.com/sandrolain/httpcache from 1.4.0 to 1.4.2.

Release notes

Sourced from github.com/sandrolain/httpcache's releases.

v1.4.2

Changes since v1.4.1

• docs(changelog): update for version 1.4.2 release (3d7b699)
• fix: resolve trivy high vulnerabilities (2652355)
• fix: resolve govulncheck issue (243d20c)
• fix: resolve linter issue (22ce42c)

Full Changelog: sandrolain/httpcache@v1.4.1...v1.4.2

v1.4.1

Changes since v1.3.0

• docs(changelog): update for version 1.4.1 release (7a36a36)
• Merge pull request #3 from andig/fix/clock-skew-future-date (474c501)
• fix: clamp current_age to >=0 for future Date headers (RFC 9111 §4.2.3) (c8c812f)
• docs(readme): update RFC compliance to RFC 9111 (d376920)
• Merge branch 'next' into develop (71d0871)
• feat(docs): add DisableWarningHeader for RFC 9111 compliance (3cd2944)
• feat(docs): add authorization handling in shared caches (6c306f8)
• feat(vary): implement RFC 9111 compliant vary matching (97254dd)
• feat(cache): implement Cache-Control directive validation (5b74cd5)
• feat(age): implement RFC 9111 age calculation and validation (a039b6c)
• feat(cache): add support for must-understand directive (ba338eb)
• feat(vary): implement RFC 9111 compliant vary separation (0136e82)
• feat(cache): add support for public cache mode (9066d71)
• docs(readme): update cache invalidation details for RFC 9111 (ff0c7dd)
• feat(httpcache): update cache invalidation per RFC 9111 (773f377)

What's Changed

• fix: clamp current_age to >=0 for future Date headers (RFC 9111 §4.2.3) by @​andig in sandrolain/httpcache#3

New Contributors

• @​andig made their first contribution in sandrolain/httpcache#3

Full Changelog: sandrolain/httpcache@v1.3.0...v1.4.1

Changelog

Sourced from github.com/sandrolain/httpcache's changelog.

[1.4.2] - 2026-06-24

This release focuses on security hardening and CI/tooling stability while preserving backward compatibility.

Changed

• Updated vulnerability scan task to use govulncheck -scan=package ./... to avoid current symbol-scan runtime panic in this environment.
• Updated contribution instructions to use the same stable govulncheck invocation.

Security

• Upgraded key dependencies to address known vulnerabilities and reduce scanner findings:
  • golang.org/x/net to v0.55.0
  • google.golang.org/grpc to v1.79.3
  • go.opentelemetry.io/otel and go.opentelemetry.io/otel/sdk to v1.44.0
  • golang.org/x/crypto to v0.52.0
  • github.com/nats-io/nats-server/v2 to v2.14.2
  • github.com/testcontainers/testcontainers-go and module packages to v0.43.0
  • github.com/jackc/pgx/v5 to v5.9.0
• govulncheck -scan=package ./... reports no vulnerabilities affecting project packages.
• Trivy HIGH/CRITICAL scan for go.mod is now clean (0 findings).

Verification

• Full task check pipeline executed successfully after updates (fmt, lint, govulncheck, trivy, licenses, test, test-integration).

[1.4.1] - 2026-06-22

Fixed

• RFC 9111 §4.2.3 Clock Skew Handling: Fixed freshness calculation for responses with future Date headers. The apparent_age is now correctly clamped to >= 0 using max(0, response_time - date_value). This prevents responses with no freshness information (no Cache-Control/Expires) from being incorrectly marked as fresh when the server clock is ahead of the client clock. Applied fix to isActuallyStale(), getFreshness(), and checkStaleIfErrorLifetime() functions.
• Added regression test TestFreshnessFutureDateClockSkew to verify proper handling of clock skew scenarios.

---

Commits

• 3d7b699 docs(changelog): update for version 1.4.2 release
• 2652355 fix: resolve trivy high vulnerabilities
• 243d20c fix: resolve govulncheck issue
• 22ce42c fix: resolve linter issue
• 7a36a36 docs(changelog): update for version 1.4.1 release
• 474c501 Merge pull request #3 from andig/fix/clock-skew-future-date
• c8c812f fix: clamp current_age to >=0 for future Date headers (RFC 9111 §4.2.3)
• d376920 docs(readme): update RFC compliance to RFC 9111
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)