WebServices: how to accept http OPTION method request?

[cirrusio]

This is not an explanation of what you are trying to do.  I agree that Mike has not given you an answer (and the option to use a "real web server" is often not a real option for many of us), but it might be more helpful if you can explain exactly what you are trying to do?  What I see here is an attempt to send an http request using the PUT method via a jQuery ajax call, but

• why are you using PUT?
• what is data&colon and I have never seen this format for a call - is it valid)?
• what is the ultimate response of the server expected to be?
• can you provide the web server VI that is supposed to respond to the request (this might help elucidate what you are trying to do)?

Thus far, I have not run into issues that are unsolvable while using the NI web server, but maybe you are trying to do something that I have never tried to do before.  Anyways, provide more information and maybe we can provide more insight.

Cheers, Matt

[cirrusio]

Mike, This answer seems rather flippant.  Do you understand ultimately what he is trying to do?  And you believe that there is no way to do what he wants to do other than using a "real web server"?  I think that we all understand that there are limitations to the web services (no gzip??), but surely this is not one of the issues.  To put together another web server would provide significant investment in time and hardware.  Surely, there is another way to skin this cat....  Matt

[dbonura]

Hi Matt,
first thanks for you answer....change the Web Server is not a way, i mean here there are few developer teams and we have to integrate services developed with .net and LabView.
About your questions:

• We use PUT because Restfull web server uses it: http://www.restapitutorial.com/lessons/httpmethods.html and labview permits that methods
• data&colon it is just an encoding error on this forum...it is just a simple json data like data:{"data":"test"}
• the response of web server has to be normal, the main problem is that the VI it is not called anyway because the preflight OPTIONS generate a 404 error
• there is nothing special about the VI...just do a normal one and try.

So to replicate the problem:
1) develop a simple VI with PUT method
2) develop an html with a simple button and ajax call as i wrote on earlier posts.
3) run the page on different domain so CORS is needed
4) check chrome network panel and notice that OPTIONS call generates the 404 error on browser

I just repeat that it is the standard way to implement CORS...so how to do it with LabView Web Server?

[dbonura]

Hi Matt,

did you try on your own to make some tests on OPTIONS request?

Thanks!

[kranthikiran01]

Hi, I am facing a similar problem. I have implemented the web service and also added the Access-Control-Allow-Origin header with value as '*'(wildcard). I have no issues while on the debugging server, but I get 404 when I have built and run the application into an exe. Did anyone face similar problem? Any solution/fix to this 404 issue? Thanks in advance 🙂

[dbonura]

There is no way to have the "OPTION" method supported....and it is really sad.

The only solution i found is to run "chrome" in unsecure profile: "--disable-web-security" command option....but it is really a BAD solution!

Any official response/reason from NI ?

[Ravenink]

Hi all,

I know this is an old topic but I'm facing EXACTLY the same problem dbonura faced and described. I get an 404 error when the preflight OPTIONS request is sent from the client. Please note the preflight OPTIONS request is absolutely necesary (and automatically performed by web browsers) in CORS situations.

Is there really no way to handle OPTIONS requests in LabView? If that's the case, web services implementations are really limited in LabView.

[dbonura]

No way. We have re-implemented web server...big effort for us! But now it is stable, really fast, and full customizable!

[Ravenink]

Thank you for your response, dbonura.

It is really depressing, though. I guess I'll need to go for an implementation using the TCP connections block in the Data Communication palette then.

[cirrusio]

So, I apologize for never responding - this is actually the first response that I have seen since my last post.  Regarding the initial post - I now see the issue.  I gave a presentation the other day at our local CLD Summit on web services and came across this exact issue.  I actually think this issue might be solvable and am a little surprised that no NI AE has popped in.  This is a server configuration issue and the server is configurable but unfortunately the documentation is not sufficient. 

There are several files to look at here that are associated with the web service - WebService.ini in [Labview]/resource/webserver/services/LVWSSysAdmin and niwebserver.conf under [Labview]/resource/webserver.  And there may actually be more that I am not aware of.  But, it might be worthwhile for an AE to become involved as this is an irritating issue.  Basically, we need to be able to set the server header to

Access-Control-Allow-Methods: "PUT, OPTIONS"
Access-Control-Allow-Origin: "*"
Access-Control-Allow-Credentials: true

I THINK this is doable, but we need to know the levers that we can pull.