1) The consumer shouldn't need a whole series of checks just to actually do
things correctly and be *compliant* with the http specs

2) I don't see how "compliant" is misleading to be "compliant" with how
things are SUPPOSED to work in the first place

On Thu, Jan 16, 2020, 05:09 Maxim Dounin <mdounin@mdounin.ru> wrote:

> Hello!
>
> On Wed, Jan 15, 2020 at 01:51:34PM -0700, sampsonsprojects@gmail.com
> wrote:
>
> > # HG changeset patch
> > # User Sampson Crowley <sampsonsprojects@gmail.com>
> > # Date 1579118065 25200
> > # Wed Jan 15 12:54:25 2020 -0700
> > # Node ID 4ba211814386f2e4adcd855b27d7d2534a5036a7
> > # Parent 8a7b59347401bba7b018c7292409ab095ce83466
> > Add "compliant" option to ssl_verify_client for CORS support
> >
> > The CORS Spec specifically prohibits any form of credentials
> > during preflight checks. Because "on" fails ALL requests if
> > a certificate is not provided, it becomes impossible to use
> > "ssl_verify_client on;" with spec compliant browsers and CORS,
> > namely Firefox. I didnt want to break any configs that rely on
> > or prefer that failure to occur, so I added an additional option
> > to allow only OPTIONS requests to bypass the client certificate
> > validation.
>
> Thanks for the patch.
>
> In no particular order:
>
> - The argument name suggested looks wrong and misleading, it says
> nothing about what the particular setting is expected to do.
>
> - The behaviour you are implementing can be configured without any
> additional arguments, by using "ssl_verify_client optional;" and
> appropriate checks during request processing. For example:
>
> ssl_verify_client optional;
>
> set $allow 0;
>
> if ($ssl_client_verify = OK) {
> set $allow 1;
> }
>
> if ($method = OPTIONS) {
> set $allow 1;
> }
>
> if (!$allow) {
> return 496;
> }
>
> While the currently required configuration might be a bit too
> complex for typical tasks, using CORS with SSL certificate
> verification is probably rare enough to don't care. On the other
> hand, if we nevertheless want to simplify it, a better solution
> might be to do this with a simplier checks during request
> processing, instead of introduction of a CORS-specific argument to
> an SSL-level configuration directive.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel