WebServices: how to accept http OPTION method request?

[MilanR]

@Ravenink if it is helpful there are certain CORS configurations that LabVIEW Web Services can respond to when receiving requests from a Web Application running in a Web Browser or when receiving a request from a WebVI created by the LabVIEW NXG 2.0 Tech Preview.

This category of requests is known as "Simple Requests" in the MDN CORS help topic. Simple requests can be summarized as follows:

• Use a GET, HEAD, or POST to make the request.
• Include only CORS-safelisted request-headers in the request.
• Set the Content-Type request header to one of the following values:
  • application/x-www-form-urlencoded
  • multipart/form-data
  • text/plain

 If your web application is capable of being modified to make only requests that fall into the simple request category then it is possible to make your web server using LabVIEW Web Services.

Also it is worth considering that CORS Simple Requests and CORS Non-Simple Requests are only concepts important when dealing with a cross-origin / CORS configuration. Another possible alternative with LabVIEW Web Services is to host your web application as static resources. When the web application files are hosted as static resources within your LabVIEW Web Service then HTTP requests created by the web application will come from the same origin as the LabVIEW Web Service and the HTTP requests will not have the restrictions imposed by the CORS mechanism.

[Ravenink]

Hi Milan,

Thanks a lot for your response.

Yes, you are right about everything. The problem appeared because the Content-Type value we were sending was set to "text/xml" (we are sending and xml message in the POST payload). We can, indeed, use text/plain without any big concern. Actually, I made this change two days ago to solve the problem. However, I see this like a workaround, and not an ideal solution, which would be to have the OPTIONS requests implemented in the LabView web services.

Thanks again!

[jonas.d]

I know this is an old topic, but it is still really frustrating. As Ravenink already argued, the proposed workarounds are not acceptable. We run simulation services in .NET WCF which mimic the behavior of RT targets. Therefore, we rely on standards such as CORS preflight and correct content-type headers.

The good news is, we got OPTIONS (partly) working by modifying the *.lvproj file by hand.

<Item Name="DispatchOptions.vi" Type="VI" URL="../path/to/DispatchOptions.vi">

  <Property Name="ws.buffered" Type="Bool">true</Property>
  <Property Name="ws.includeNameInURL" Type="Bool">false</Property>
  <Property Name="ws.keepInMemory" Type="Bool">true</Property>
  <Property Name="ws.loadAtStartup" Type="Bool">true</Property>
  <Property Name="ws.method" Type="Int">5</Property>
  <Property Name="ws.outputFormat" Type="Int">2</Property>
  <Property Name="ws.outputType" Type="Int">0</Property>
  <Property Name="ws.permissions" Type="Str"></Property>
  <Property Name="ws.requireAPIKey" Type="Bool">false</Property>
  <Property Name="ws.type" Type="Int">1</Property>
  <Property Name="ws.uri" Type="Str">api/*path</Property>
  <Property Name="ws.useHeaders" Type="Bool">true</Property>
  <Property Name="ws.useStandardURL" Type="Bool">false</Property>
</Item>

LabVIEW even knows what ws.method 5 means:

It works in most cases, but unfortunately not in all. For some URL configurations, the service reports "One or more URLs conflict!" and it doesn't start. It's totally unclear to me how URLs can conflict if they all use different HTTP methods.

@NI: Why isn't it possible to define a "handle all VI" that gets called for any HTTP method and for any URL within a base URL?

[Mikael-ANSCENTER]

I tested the method of changing the ws.methods to 5/OPTIONS.
Have anyone solved the issues of "One or more URLs conflict!"