<div dir="auto">What if it's changed to "preflight_optional" or "on_spec_compliant" is that a better description in your opinion?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 16, 2020, 08:18 Sampson Crowley <<a href="mailto:sampson@downundersports.com">sampson@downundersports.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>1) The consumer shouldn't need a whole series of checks just to actually do things correctly and be *compliant* with the http specs</div><div dir="auto"><br></div><div dir="auto">2)  I don't see how "compliant" is misleading to be "compliant" with how things are SUPPOSED to work in the first place<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Thu, Jan 16, 2020, 05:09 Maxim Dounin <<a href="mailto:mdounin@mdounin.ru" target="_blank" rel="noreferrer">mdounin@mdounin.ru</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<br>
On Wed, Jan 15, 2020 at 01:51:34PM -0700, <a href="mailto:sampsonsprojects@gmail.com" rel="noreferrer noreferrer" target="_blank">sampsonsprojects@gmail.com</a> wrote:<br>
<br>
> # HG changeset patch<br>
> # User Sampson Crowley <<a href="mailto:sampsonsprojects@gmail.com" rel="noreferrer noreferrer" target="_blank">sampsonsprojects@gmail.com</a>><br>
> # Date 1579118065 25200<br>
> #      Wed Jan 15 12:54:25 2020 -0700<br>
> # Node ID 4ba211814386f2e4adcd855b27d7d2534a5036a7<br>
> # Parent  8a7b59347401bba7b018c7292409ab095ce83466<br>
> Add "compliant" option to ssl_verify_client for CORS support<br>
> <br>
> The CORS Spec specifically prohibits any form of credentials<br>
> during preflight checks. Because "on" fails ALL requests if<br>
> a certificate is not provided, it becomes impossible to use<br>
> "ssl_verify_client on;" with spec compliant browsers and CORS,<br>
> namely Firefox. I didnt want to break any configs that rely on<br>
> or prefer that failure to occur, so I added an additional option<br>
> to allow only OPTIONS requests to bypass the client certificate<br>
> validation.<br>
<br>
Thanks for the patch.<br>
<br>
In no particular order:<br>
<br>
- The argument name suggested looks wrong and misleading, it says <br>
  nothing about what the particular setting is expected to do.<br>
<br>
- The behaviour you are implementing can be configured without any <br>
  additional arguments, by using "ssl_verify_client optional;" and <br>
  appropriate checks during request processing.  For example:<br>
<br>
    ssl_verify_client optional;<br>
<br>
    set $allow 0;<br>
<br>
    if ($ssl_client_verify = OK) {<br>
        set $allow 1;<br>
    }<br>
<br>
    if ($method = OPTIONS) {<br>
        set $allow 1;<br>
    }<br>
<br>
    if (!$allow) {<br>
        return 496;<br>
    }<br>
<br>
While the currently required configuration might be a bit too <br>
complex for typical tasks, using CORS with SSL certificate <br>
verification is probably rare enough to don't care.  On the other <br>
hand, if we nevertheless want to simplify it, a better solution <br>
might be to do this with a simplier checks during request <br>
processing, instead of introduction of a CORS-specific argument to <br>
an SSL-level configuration directive.<br>
<br>
-- <br>
Maxim Dounin<br>
<a href="http://mdounin.ru/" rel="noreferrer noreferrer noreferrer" target="_blank">http://mdounin.ru/</a><br>
_______________________________________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org" rel="noreferrer noreferrer" target="_blank">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" rel="noreferrer noreferrer noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
</blockquote></div></div></div>
</blockquote></div>