@@ -2,8 +2,6 @@ Generally things to be done with ``caddy-frontend``:
* return warning on not implemented keys (from ``apache-frontend`` perspective) in master and slave request
* tests: add assertion with results of promises in etc/promise for each partition
* tests: compare python objects where possible instead of instead of strings (eg. load ``rejected-slave-dict``)
* tests: swich to `cryptography <https://pypi.org/project/cryptography/>`_ for certificate management
* README: cleanup the documentation, explain various specifics
* check the whole frontend slave snippet with ``caddy -validate`` during buildout run, and reject if does not pass validation
* ``apache-ca-certificate`` shall be merged with ``apache-certificate``
...
...
@@ -15,7 +13,6 @@ Generally things to be done with ``caddy-frontend``:
* ``type:eventsource``:
* **Jérome Perrin**: *For event source, if I understand https://github.com/mholt/caddy/issues/1355 correctly, we could use caddy as a proxy in front of nginx-push-stream . If we have a "central shared" caddy instance, can it handle keeping connections opens for many clients ?*
* ``ssl_proxy_ca_crt`` for ``ssl_proxy_verify``, this is related to bug `#1550 <https://github.com/mholt/caddy/issues/1550>`_, proposed solution `just adding your CA to the system's trust store`
* ``check-error-on-caddy-log`` like ``check-error-on-apache-log``
* cover test suite like resilient tests for KVM and prove it works the same way as Caddy
* have ``caddy-frontend`` specific parameters, with backward compatibility to ``apache-frontend`` ones:
"description":"[NOT Implemented] If set to true, Backend SSL Certificates will be checked and frontend will refuse to proxy if certificate is invalid",
"description":"If set to true, Backend SSL Certificates will be checked and frontend will refuse to proxy if certificate is invalid",