Flash Chart, Sideview PostProcess and IE max URL/GET length limitation

[greg]

I came across this weird issue when using FlashChart along with PostProcess and long search strings in my advanced XML dashboard. It happens in Internet Explorer only.

The FlashChart displays "Results Error: Error #2032" when the PostProcess string is too long.
So that the resulting GET query hits well-known IE limitation on URL/GET max length (< 2083 bytes).

In web_access.log, I see the entire PostProcess search text whilst the main non-PostProcess search is referred by job ID and its URL is nice and short. I guess those long queries are rejected by IE and FlashChart fails to render.

The questions are:
1. Is it a Sideview Utils issue?
2. Is there any workaround?

Of course, the search length can be reduced somehow, but I wouldn't like to do reduction all the time for future searches.
Changing IE to other browser is not the case as well since our customer uses it.

--
Some futher details.

My typical advanced XML dashboard schematically looks like:

...
  <module name="Search" autoRun="False">
     ... | stats x by y
     ...
       <module name="PostProcess">
         rename x as "something"
         ...
             <module name="FlashChart">
 ...

In the PostProcess, I usually do a lot of field renaming to localize them, and the search itself also requires a certain space.
Eventually it turns to a pretty long string in GET with each symbol %-encoded, and such long URL is discarded by IE.

Basically, Splunk doesn't embed search text into GET query as it replaces it with the job ID.
Sideview Modules recompose the query by appending postProcess search text as a parameter.

SideviewUtils.js:

augmentLastKnownSavedSearch: function(triggeringModule)
    ...
    $.get(url, function(jsonResponse) {

Fomatted in this way, the GET query length becomes > 2083 bytes and is discarded by IE.
Could it be changed to POST?

[sideview · Accepted solution]

OK. I think you're right to suspect URL length. Certainly if you've measured the full URL and found it to exceed the magic IE number.

So it is ultimately a Splunk/Flash/IE issue and not something that we can fix from the Sideview app.
However there are workarounds.

1) Use macros in your postprocess search. You can use a combination of simple macros with no arguments, as well as macros with one or more arguments, to simplify and shorten your postprocess search. Note that the length of the main search string isn't relevant here because that is sent up via a POST.

2) Use JSChart instead of FlashChart.

Sorry that it's not something that Sideview Utils can patch for you.

[greg]

OK, I see. Macros sound like a worthwhile option to try, though they shoud be statically preconfigured before runtime.

Thanks for useful hints!

[sideview]

This question may seem a bit random but what happens if you change to JSChart, out of curiosity? You're probably using FlashChart because you prefer it, or because you need some advanced charting framework key that JSChart doesn't do, but I'm curious nonetheless if the problem in IE goes away.

Beyond that the best workaround is probably going to be using macros to shorten the postprocess string.

[greg]

Thank you for the comment, I have tried it and here it is.
There is no such problem with JSChart. Even more, no such problems, say, with SimpleResultsTable or Table placed instead of FlashChart - it's displayed correctly.

So, answering the Q1, looks like it's not a Sideview Utils issue.
Maybe this is a weird FlashChart issue, or even a flash player problem in IE, but URL length limitation is really the root cause.

I do use some advanced charting on this dashboard like chart overlays (mixing lines and columns) and some other stuff, so I don't want to be limited by JSChart. But it's a good point to think about it as a simpler alternative when needed.

Q2: As for macros, won't they be unfolded to the same long string as the original PostProcess when transformed to GET query? The problem here is with final URL which goes to the server, not with the search text size in advanced xml.