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
