Greetings everybody! Thank you for your responses. > Given the previous discussions referenced from the working groups for xmlhttprequest I think it's pretty clear that we can forget about OPTIONS *. Just using a > custom verb and implementing it in the xmlhttprequest implementation of qml seems like the way to go. Ok. Then https://codereview.qt-project.org/#/c/92664/ patch can be rejected. It does not contain valuable changes. "OPTIONS" is already supported by "sendCustomRequest" and covered with tests. Should I perform any actions to reject the patch?
> By the way, do you know of who would need OPTIONS *? What's the use-case, who > would use it and how do they do it today? Unfortunately, I can't think of any specific use case except getting general server settings. For example (from specification), OPTIONS request can be used to test proxy for HTTP/1.1 conformance. Another use case for using "OPTIONS *": preflight request in case of using CORS. -- Sincerely yours, Valery Kotov
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
