I had an epiphany in the middle of the night regarding this error, the Bad Request that requires cookie clearing error, the cookie is getting so big because I set the session length at 9hrs so you guys would not have to log back in often. The cookie grows with each page you visit and, since the session is so long, the cookie gets too big for the server (for the setting on the server). The host just doubled the size of the cookie, we will see if that helps us for awhile. If it still doesn't fix it I have to figure out how to control what is stored in the cookie, if any of you geniuses out there already know how that works with joomla/jomsocial/kunena please share.

cyber steve wrote:
Your epiphany was probably more a deja-vu experience than a true epiphany. I described the reason for the error about two weeks ago (string length in the "Where's the Damn Forum" thread).

The session timeout is a contributing factor but the string length is a consequence of user interaction. It would be relatively simple to determine if logging out clears the string as stored in the cookie. My guess would be that it doesn't.

Doubling the size of the acceptable data content will delay the error occurrence but not correct it.

In my experience, this type of string length problem has to do with static allocation of memory for a data type versus dynamic allocation via a pointer. That is not something you can correct via a template change. It requires a change at the code level.

The secondary issue beyond data typing is code logic or in simpler terms, how the data is stored and managed versus static or dynamic allocation of memory for that storage.

In example, I may want to track what "forums catagories", "threads" and "last post" entries the user last reads. I'll do that by keeping a list of each URL (actually a directory/file entry). If that list is a literal, alphabetic listing, the string length will quickly grow huge as the user browses the forums. As the developer, I can allocate a static quantity of server memory to accommodate that lengthy string or I can set a pointer to the first character of the string then dynamically allocate memory at need. Either way, I'll end up using a lot of memory and have really long strings to parse as I track the user's browsing history. If you have a background in the 'C' programming language, a cursory review of the 'alloc' and 'malloc' functions will offer more insight. You'll find similar functions in nearly all languages.

Determining what data types to use and how memory is allocated is one step. Determining the parsing algorithm is more important. Perhaps instead of using literal strings within the code, a more efficient methodology would be to create a table of integer/URL string relationships.

In example....

Instead of storing the string....

"www.horseshoes.com/forum/9-farriers-helping-farriers/...."

I assign the integer or character '1' to "www.horseshoes.com", the integer/character '2' to forum' and the integer/character '3' to "farriers-helping-farriers", etc.

Now my tracking/storage string has changed to....

"1,2,3".

The comma character is my delimiter for each string element of a single tracking location and the semi-colon becomes my delimiter to separate complete URL locations.

The code developers have already used at least some of this methodology. Unfortunately, the process is incomplete, leaving lengthy, literal strings embedded within the cookie. They may have done this for performance reasons (reduced parsing time).

This is an over-simplified explanation but gives you at least a starting point for your discussions with the developers of the forum code.

The bad news is that this represents an extensive change to the underlying program codes.

Cheers,
Mark

My epiphany was the session length contribution, if it is true, I have meetings this morning but will mess with it again this afternoon. When I increased the size of the cookie the first time it seemed to all but fix the problem for me but others still had the problem. The registered users are trying to stay logged in but it dawned on me last night that I almost daily purposefully log out to test things as registered users. Therefore, perhaps, it is caused by the session length if you run through many threads over the 9 hours. Just a thought, still much to figure out to prevent the need to log in periodically (which seems quite important to several of my most active users). Thanks so much for your summary, you are an appreciated resource for this issue Mark.

If this is a joomla kunena issue are you reproducing these errors on a test sure with base joomla and kunena?

I had these same errors with a 30 min session.

Eric Russell

Are we sure it's not a problem in the boobla boobla section of the gamma quadrant in the purple people eater star system???

You guys are talkin a whole 'nother language.

Thanks for all your hard work!

Buttermaker wrote:
you took the words right out of my mouth.

Eric Russell wrote:
That was my point Eric. I don't think the issue is session length per se, but rather, how quickly the user builds history via browsing. When the string length exceeds the fixed value assigned the pointer, the application rejects. Looks like their parsing algorithm checks length to avoid errant pointers.

Cheers,
Mark

Buttermaker wrote: Nope. Is a combination of object bloat accompanied by a simultaneous return stack overflow which resulted from a "goto" violation of Djikstra's construct compounded by a general rejection of the Böhm-Jacopini theorem.

The godless infidels who ignore the teachings of the prophets and fail to follow the commandments are destined to suffer the perils of the doomed.

1. Thou shalt not place the Left Curly Brace on a line of its own; this shows disrespect to thy Fathers and thy Mothers who only had 80 columns and 24 lines in days of old
2. Thou shalt not use the GoTo, for such disrespects the Prophet of Programming Dijkstra,
3. Thou shalt comment thy code, and provide great detail about the workings of thy mind when thou does first write thy method. And thou shalt revisit and revise thy comments only in the earliest hours of the morning prior to thy code review.
4. Honor thy Sun and thy Java that your days may be long upon the Virtual Machine where thy code livith.
5. Thou shalt Compile before checking in.
6. Thou shalt Run thy code at least once before shipping.
7. Thou shalt Test at least one Browser against thy Server's code, and thy backup Server's code, and thy Neighbor's Server's code.
8. Thou shalt not covet thy neighbor's operating system unless thy neighbor runs Linux; If ye cast your eye upon thy neighbor's Windows Server, and covet it in thy heart, thy staff shall take thee into thy parking lot and stone thee with mice until the demon of ******ity leaveth thee
9. Thou shalt not make libraries of other gods such as C# or Perl. These are an abomination before thy God.
10. Once thou hast compiled thy code, generated thy Java Doc, Reviewed thy code with the elders of thy people, Deployed thy code upon thy server, and tested thy code upon the Browser of thy God (Firefox 3.0), and thy customer doth stumble upon thy bug, thou shalt blame thy customer with thy mouth, and curse his existence, for thou hath commented, placed thy braces properly, indented with four spaces (and not eight as do the godless), hath capped thy constants, hath lowercased thy methods, and hath passed all thy JUnit tests..... It is the truth of God that if yee hath done all these things, thy customer must be at fault.

Now my PC won't boot, even from a recovery boot disk. LOL, I just have to laugh at this point.

Back to my notebook and off to a repair shop with the PC, it's not even a year old, don't recommend Dell all-in-one's, too much heat I think due to monitor and processor all being in the same tight spot. May be time for a Mac.

I'm going to work on the cookie issue sometime today. The cookie setting is so large at my server limit now that by the time it blows up it is 4 pages long! But I still got it to send the bad request eventually. I think it is going to take coding to fix. So, as Mark and others thought, not session related.

Happy Valentines Day!

cyber steve wrote:

A program is only debugged until you turn it over to the public.

Just happened to me again.

that's what I was saying, the huge cookie only postpones the need to clear it

Steve...

Thanks for your hard work to keep this site running for us.

Buttermaker wrote:
I so appreciate you and and those who have been supportive of me.

Steve I use Google Chrome and it seems I have to clear my cookies every weekend! Fortunately its easy enough but aggravating.Kind of like a horse who leans on you! The roll over menus are a pain. Glad the site is back up and under way even if it feels like we have cylinder missing.