On Friday 12 September 2014 01:19:30 Valery Kotov wrote: > 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?
Abandon it. > > 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. Most proxies are HTTP/1.0... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
