Web Service URL length limits, LV2013 vs LV2012

[mjaspan]

(* CROSS POST: http://lavag.org/topic/18435-web-service-url-length-limits-lv2013-vs-lv2012/ *)

(* Please reply in this forum.  I have marked the other thread to put replies here. *)

Has anyone noticed a reduction to the limit on URL length for Web Services between LV versions 2012 and 2013?

Under LV2012, a RESTful web service appears to accept URL with lengths at least as long as 4096 characters.  With LV2013, the max URL length appears to be 511 characters for both RESTful and Project Item web services. Unfortunately for me the project I just converted trips over this issue. My goal with posting this query to here is to improve my understanding of this limitation before I decide how best to modify my code.  Certainly using POST rather than GET with a long URL is an option, but again, I'm looking to understand the change in limitation before I choose a solution.

To illustrate I have attached three mostly identical projects which demonstrate the issue.  In each case the project contains a webservice consisting of a single VI, "ComputeLength", which takes a String as an input parameter and which outputs the length of the string.  The three projects are as follows.

1. LV2012 RESTful web service.

2. LV2013 RESTful web service.

3. LV2013 Project item web service.

The web service contains a single VI.  For the RESTful examples, the web service is started by selecting Deploy from the Build specification right click menu.  For the Project Item example, the web service is started by selecting Start from the MyComputer/WebService right click menu. The use of this example is demonstrated with the following URL: 

(note that the port is 8080 for the two RESTful examples and is 8001 for the Project item web service if used in Debug mode, which is the default for the above instruction.)

http://localhost:8080/webservice/computelength?string=1234567890

And the output looks like this.

<Response>

<Terminal>

<Name>StringLength</Name>

<Value>10</Value>

</Terminal>

</Response>

To see the issue, extend the string parameter such that the URL contains more than 511 characters beyond the port number.  For example something like this, http://localhost:8080/webservice/computelength?string=1234567890123456789012345678901234567890....(keep repeating)

For the LV2012 example the string parameter may be at least as long as 4000 characters, which I've demonstrated using Chrome as my browser.  For both of the LV2013 examples the URL is limited to 511 characters after the localhost and the port number.

Anyone know whether this is a bug or this is an intentional design change?  How about whether the URL length limit is configurable? 

I am also consulting NI tech support and will report back their response.

Any advice appreciated.

Thanks,

  Martin

[mjaspan · Accepted solution]

Solution found.  Apparently starting in LV 2013, there is a default limit of 512 to the URL length.  The default limit may be overridden as described below.

Martin

This is Brian in Applications Engineering from National Instruments. I am following up regarding the 511 character limit in your Web Service HTTP request following the port number. After some research I've figured out that the issue is related to a default web server setting called "LimitUri," which limits the maximum length of a URL. The default setting is 512 characters which is why we are seeing this issue.

There are multiple ways of changing the URL length limit depending on how you are using your web service. If you are publishing the web service using the Application Web Server then modify "C:\Program Files (x86)\National Instruments\Shared\NI WebServer\NIWebAppServer.conf" and add "LimitUri 4096" to the end of the file without the quotes.

If you are running the Debug Web Server by just clicking start on the web service then modify "C:\Program Files (x86)\National Instruments\LabVIEW 2013\resource\webserver\niwsdebugserver.conf" and add "LimitUri 4096" to the end of the file without the quotes.

[soren_jensen]

I would like to "reopen" this thread. For several years I have been running a web-server (in LabVIEW 2013) and very early on I ran into the 512 bytes limit, I found the same solution as described above and added LimitUri 8192 to the NIWebAppServer.conf file. It worked fine for several years. However, recently I have found out that the limit I set no longer is active and that the maximum limit of GET requests is now reduced to aprox. 4072 bytes. I know for a fact that I have been sending lots of messages above 5k to the server, but somehow that no longer works. Please help me idenfity where the limit is now.

Embedthis-http limituri (maximum) is 8192 bytes.

/søren

[phil_softdb]

I have noticed a similar behavior. I added the LimitUri parameter to the .conf file. It works fine up to 4000 bytes, but setting LimitUri to an higher value still keeps the 4000 bytes limit. Is there anyway to increase the limit to higher than 4000?

[Jorr-El]

Hi søren,

In order to further investigate this behavior, it would be good to get copies of your VI, or at least a reproducing case, and possibly a copy of your NIWebAppServer.conf file.

Furthermore, to help this question get more visibility, I'd recommend that you make a new Forum Post and ask your question with the VI/config file(s) above. It is difficult to monitor and ensure new posts are seen and answered from older and already solved threads.

Thanks!

Jason O.

Applications Engineer

National Instruments

[soren_jensen]

Jason,

The behaviour is completely independent of any VI and also independent of the NIWebAppServer.conf file (although it should not be). Trying to document it with an example serves little purpose. Please explain why this should be needed. The user mjaspan has already attached examples in the thread above. 

As mentioned above, I observe that the LimitURI of the conf file cant be set any higher than 4096 bytes, at least it has no effect setting it higher than 4096. This is not a native limit of the underlying appweb/httpthis server (https://embedthis.com/appweb/doc/) , which supports way higher settings. https://embedthis.com/appweb/doc/users/dir/sandbox.html

So the limit must be introduced in the labview wrapper/top layer. Historically there was a labview-maximum of 8192 bytes in the conf. file and this was fine for my needs, but this limit has now been altered and seems to be only 4096 bytes now. What further is very strange is that the change happned without upgrading the LabVIEW version.

 I observe this failure on my website www.pendlernet.dk. The site has been online since 1996 and has been running in LabVIEW from 2001 and onward, it runs a carpool service with aprox. 15000 members. It started its existence running on Unix/Perl. However, from 2001 to 2013 it used the NI web-server that came with the internet toolkit.  When LabVIEW 6i came out, NI seemed to stop development of the Internet toolkit - which is a bit ironic when you know what the i stands for - and over the years I maintained the package myself because it kept 'breaking' and becomming more unstable caused by more and more visious internet attacks.

Embedding a web-server in VIs seemed to rescue my service on the brink of extinction. However, there is little programatic control of the appweb server and itd does have a tendency to be more protecttive than is needed, when for instance it detects a DDOS attack where there is in fact none. This has happned to me on several occations, and its frustating when there is no programatic control from labview and your VIs thus cant know if the server is up or down. 

Anyhow, I have discussed this issue with NI earlier and on 6/16/2014 I received this from one of the NI programmers.  Unfortunately I dont have this persons email or name.

"Is the customer asking about the INI file, or the Appweb .conf file? The two are related but separate. The .conf is very order-dependent (and much more complicated than the INI file). Manual edits to the conf are even more un-supported, and there was a massive change to the format in 2013.

That said, if the customer absolutely must edit the configuration file... The 2013 server is Embedthis Appweb 4.1, which has public documentation athttp://appwebserver.org/products/appweb/doc-4/guide/appweb/users/configuration.html. I will repeat that changes to this file are notsupported and are very likely to break in a future upgrade. The configuration directives may not even work as documented (we've seen a few cases where using them breaks the server entirely), so be sure that the customer tests their application thoroughly.

I hope this helps clarify the issue, I for one would certainly like to get a fix for this problem.

/søren jensen

happy labview programmer since 1997

[eltico]

Hello Søren,

I've searched internally for the interaction you had in 2012 and I found an internal forum where this subject was touched. The NI APP Web server is not really going to have the same sort of documentation that many production web servers (like Apache) have and that's why you are missing some information.

There is a CAR about larger Application Web server system where the ini file needs to be changed, in the end, the solution provided was to avoid too many clients. The issue is that this is not supported and the information about it is quite limited. I am not sure if back in 2012 you got some documentation but I am forwarding a white paper that is not public or maintain anymore but it's on the forum and it seemed to be possible to publish it.

Our main problem is that some of this information is classified, I am afraid that sharing security information is not possible as far as I know from that post. The information available for the public should be enough for the applications that Web Server was made for.

Thanks for your understanding.

[jlokanis]

You might also want to add the line to this file if you are building your web service with your EXE:

C:\Program Files (x86)\National Instruments\LabVIEW XXXX\resource\webserver\niembeddedws.conf.defaults

Also: this issue still exists in LV2015.  Not sure about later versions.  And the limit is 498 chars in 2015 if you do not use this fix.

This is a really nasty bug since the default limit is not documented anywhere.  It really should be eliminated since the normal limit for URLs is 65535 chars in most other languages.