[Development] QTBUG-35892. QML XMLHttpRequest does not support the OPTIONS method.

[Валерий Котов]

2014-09-06 20:03 GMT+03:00 Jeremy Lainé <jeremy.laine at m4x.org>:

>  On 09/06/2014 01:19 PM, Валерий Котов wrote:
>
>  There is one more thing. Should we care about cross-origin resource
> sharing protocol? If I got it right, XMLHttpeRequset should perform
> "OPTIONS" preflight request before real cors request. Please see links
> below for more details:
> http://www.w3.org/TR/cors/#cross-origin-request-with-preflight-0
>  Does it make sense to have separate method for "OPTIONS" request in
> QNetworkAccessManager if it is the case (like for get or post)?
>
>
> From the docs:
>
>    - QML's XMLHttpRequest
>    <http://qt-project.org/doc/qt-5/qtqml-javascript-qmlglobalobject.html#xmlhttprequest>
>     does not enforce the same origin policy.
>
> => you don't care about cross origin requests, much less preflighting.
>
> Jeremy
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
Thank you for the answer.

Do we need support for "OPTIONS *" http request in QNetworkAccessManager?
If no, then patch "QNetworkAccessManager: Support for "OPTIONS" method for
http request was added." for qtbase project (Change-Id:
Iad281ed4c70696b9fb93211d31ad728c41147a6e) can be rejected. qtbase already
has support for "OPTIONS" request (via sendCustomRequest). It is also
covered with tests.
If yes, how should it be performed? It is possible to send "OPTIONS"
request by using sendCustomRequest. But how should user perform "OPTIONS *"
request? Should it depend on url?

Thank you!
Valery
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140907/8511b5c7/attachment.html>