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 <[email protected]> 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 <[email protected]> wrote: > >> Hello! >> >> On Wed, Jan 15, 2020 at 01:51:34PM -0700, [email protected] >> wrote: >> >> > # HG changeset patch >> > # User Sampson Crowley <[email protected]> >> > # 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 >> [email protected] >> http://mailman.nginx.org/mailman/listinfo/nginx-devel >> >
_______________________________________________ nginx-devel mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
