nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

FormAPI callServer does not execute?

System

I have put debug statements in my code around a callServer call and I can see that the callServer is being hit and no error is resulting. But in access_log I don't see this CGI request. It works for one DCR but not for another DCR, so I assume it is some kind of data condition (something invalid in the parameters object).

Does anyone know what could cause this? Are there values that are invalid in the parameters object to callServer?

Find more posts tagged with

Comments

iwovjames

can you post some of your JavaScript so we can look it over?

Migrateduser

debug( 'setMultipleOptionLists' );
IWDatacapture.callServer( URL_multipleOptionListsCGI, params, true );
debug( 'called server' );

I get both debug alerts, but the access log never shows this request.

Thanks,

Migrateduser

Is there some limit on the number of parameters that can be passed to callServer, or a maximum length of the query string? In the case that fails it is passing dozens of parameters (several for each instance of the replicant). The DCRs for which it works have fewer of this replicant, and if I remove several replicant instances from the one that fails, it works. Also if I use post instead of get it works (but that makes it harder to debug because the parameters are not visible in access_log).

IWDatacapture.callServer( URL_multipleOptionListsCGI, params, false );

Adam Stoller

My guess is that there is a URL length limitation imposed by HTTP, the browser being used, a proxy server, or some other aspect of the network. According to http://www.jetools.com/content/resources/whitepapers/HTTP_GET_Requests.pdf it looks like the browser-imposed length limitations vary but that IE generally limits it to around 2083 characters, Netscape is supposedly much larger ...

Do you have any idea of what kind of size your URL is around the dividing line between when it works and when it doesn't?

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

JonathonG

There is definitely a URL length limitation. While the RFC spec from the W3C seems to indicate that URLs can be arbitrarily long, they also include the following note:

Note: Servers ought to be cautious about depending on URI lengths
above 255 bytes, because some older client or proxy
implementations might not properly support these lengths.

(see http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.1 for details)

If you are passing a large number of parameters, you should, as you have noticed, be using POST instead of GET. Other than parameters not showing up in access log, why wouldn't you use POST? For debugging, you could always write all parameters out to a log file from your CGI to get around the issue of not seeing the parameters in access.log.

Jonathon
Independent Interwoven Contractor

Migrateduser

I think the max query length may vary by release of IE - I remember something like 1 or 2 million characters being allowed in some 5.x version (but this was considered a security risk). Maybe that was an IIS limit not an IE limit though. I wouldn't guess that IE is limitting it because I've never hit this issue with IE before and I've worked with some pretty wacky URLs, and if it's not in the RFC I don't see why MS would limit it. I don't know what the number is that causes it to fail - would prefer Interwoven debug and document - but I would guess it is somewhere between 1000 and 3000. I guess I could URL-encode the parameters, concatenate them all together and if it's longer than some number use post, but it seems like callServer could do this for me internally without EVERY CUSTOMER HAVING TO WRITE THE SAME FREAKING CODE AGAIN.

Migrateduser

Welcome to the fun-filled world of being an Interwoven Product Suite developer. I see this again and again. There's lots of examples of basic things that almost all Interwoven customers have to custom implement.

- Jason

Migrateduser

It's much easier to see the parameters in access_log than have every CGI write a file, and I don't like writing log/temp files every time a process executes. Plus, what if the problem is that the CGI is crashing with some parameter values.

Migrateduser

Sure enough, 2083. I guess I will write a function that is passed the base URL and params object and constructs the encoded url (pitty since callServer must already be doing this), checks the length and returns whether the call should be done with get or post.

http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q208/4/27.ASP&NoWebContent=1

Migrateduser

function shouldDoPost( url, params )
{
var str = url;
var char = '?';

for( var key in params )
{
str += char + escape( key ) + '=' + escape( params[key] );
char = '&';
}

return( str.length > 2000 );
}

Migrateduser

err,

function shouldDoGet( url, params )
{
var str = url;
var char = '?';

for( var key in params )
{
str += char + escape( key ) + '=' + escape( params[key] );
char = '&';
}

return( str.length < 2000 );
}

function wrapCallServer( url, params )
{
IWDatacapture.callServer( url, params, shouldDoGet( url, params ));
return( true );
}

Migrateduser

Also when using get, I can just copy the URL parameters from the access_log and paste them into the URL field of the browser, letting me see the actual output of the callServer. Try that with post.

JonathonG

That's a valid point. To do that with post, you'd have to have a test page of some kind...blech!

So, here's hoping someone fixes the limitations in the browsers/webservers on URL length.

Jonathon
Independent Interwoven Contractor