Play Framework

feat: enable-https / disable-https now toggle play.http2.enabled together (release 1.12.20)

PF-67 follow-up: HTTPS and HTTP/2 are tightly coupled — h2 needs ALPN
which needs TLS, and the framework's h2 path requires
play.http2.enabled=true. Treating them as separate toggles meant
operators had to do two steps to get a working HTTPS+h2 setup, and
forgetting the second step left them with HTTPS-only-h1.1 (the very
gap PF-66 fixed at the SSL pipeline level). Bundling them under one
command matches user expectation: "enable HTTPS" should mean
"HTTPS that works the way modern browsers want it to."

enable-https:
- Now also sets play.http2.enabled=true via _set_or_uncomment, so
  the command is sufficient (no manual application.conf edits).
- "Already enabled" check now requires both https.port active AND
  play.http2.enabled=true. If only one is set (e.g. user manually
  edited config), enable-https completes the missing half.
- New helper _is_active_value() does case-insensitive value-equality
  matching for the play.http2.enabled=true detection.

disable-https:
- Now also comments out play.http2.enabled, since h2 over plain HTTP
  (h2c) is out of scope and was never wired up — leaving
  play.http2.enabled=true after disabling HTTPS would be dead config.
- "Already disabled" check considers both lines.

Status messages updated: "HTTPS enabled on port 9443 with HTTP/2
(ALPN h2) negotiation"; "HTTPS disabled (HTTP/2 negotiation also
disabled)".

End-to-end verified on a fresh app:
- play new myhttpsapp2 && cd myhttpsapp2 && play enable-https
  → both lines set, no manual edits needed
- play start → server starts, listens on 9443
- curl -kvs --http2 → "ALPN: server accepted h2", HTTP/200
- curl -k --http1.1 → HTTP/200, HTTP/1.1 fallback works
- play disable-https → both lines commented, keystore preserved
- play enable-https again → keystore reused, both lines uncommented,
  no duplicates

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>