What if it's changed to "preflight_optional" or "on_spec_compliant" is that
a better description in your opinion?

On Thu, Jan 16, 2020, 08:18 Sampson Crowley <sampson@downundersports.com>
wrote:

> 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