[PATCH] Add "compliant" option to ssl_verify_client for CORS support

[Sampson Crowley]

the fact is that CORS is part of the whatwg spec, endpoint consumers don't
differentiate what section of the spec it's a part of, and requiring
credentials on a preflight request is against the spec, so no, it's not
compliant. https://bugzilla.mozilla.org/show_bug.cgi?id=1019603#c9

On Thu, Jan 16, 2020 at 11:09 AM Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Thu, Jan 16, 2020 at 08:18:10AM -0700, Sampson Crowley 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
>
> You assume that CORS is a part of HTTP specification.  It's not.
> Neither it's a part of SSL / TLS specification, which is a
> separate one.  Further, all current variants of ssl_verify_client
> are HTTP-complaint, as well as SSL/TLS-complaint.  Further, I
> suspect that these are also CORS-complaint (though I never checked
> the exact wording of the CORS specification), even if some of them
> may prevent CORS preflight requests from working.
>
> > 2)  I don't see how "compliant" is misleading to be "compliant" with how
> > things are SUPPOSED to work in the first place
>
> Sure.  And things already complaint.  The question is how exactly
> things work, and what exactly happens in a given situation.
> Introducing a separate "complaint" variant suggests that other
> variants aren't complaint, which is not true.  Further, it doesn't
> define to what exactly things are expected to be complaint.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20200116/0096e56a/attachment.htm>