Serialize multi-select limit

Reported by:	scott.barnsley@hotmail.com	Owned by:	scott.barnsley@hotmail.com
Priority:	undecided	Milestone:	None
Component:	unfiled	Version:	1.8.0
Keywords:		Cc:
Blocked by:		Blocking:

Description

Hi,

I seem to have encountered a limitation in the ".serialize()" function...

For one large form (which I am processing via custom ajax form processing), I am unable to pass all of the selected values in a multi-select because in some cases, there are over 2000 options populated via ajax (appending the option elements).

Via debugging I have been able to check the number of multi-select values which were serialized in the string, which seems to hit a maximum of 1165.

I have no idea why this would occur, but it seems to be happening across all the browsers I have available to test at the moment (Chrome/Chromium, Firefox, LuaKit and IE).

This may be unrelated to jQuery and if so, I would appreciate the heads-up.

Thanks,

Scott.

Attachments (0)

Change History (4)

Changed August 29, 2012 06:31AM UTC by anonymous comment:1

Please note, the data was being passed to a "$.post" function, so GET or URL string length limits should not be a factor.

Changed August 29, 2012 12:37PM UTC by dmethvin comment:2

owner:	→ scott.barnsley@hotmail.com
status:	new → pending

Can you provide a test case? It sounds like you could paste your long select into jsfiddle.net and call serialize on it.

This may be unrelated to jQuery

Since this is the jQuery bug tracker it would be good to limit tickets to ones that are related to jQuery. If you click submit on a plain web form that has 2000 entries does it work? It seems very odd that different browsers would have the same limits.

Changed August 30, 2012 12:20AM UTC by scott.barnsley@hotmail.com comment:3

status:	pending → new

Thanks for the quick reply.

I ran a few more tests, including using jsFiddle and have found the problem.

We were using a fairly long name for the field, "customer_outlets[]", which didn't work (http://jsfiddle.net/dZfVH/2/)

but changing the name to something shorter, such as "cust_o", did work (http://jsfiddle.net/dZfVH/1/).

We see this to be a problem for 2 reasons:

1. We having naming standards we follow for all views in out web applications.

2. Once we have more outlets, are we going to encounter this issue again even with a smaller field name (http://jsfiddle.net/dZfVH/4/)?

Thanks,

Scott.

Changed August 30, 2012 01:54AM UTC by dmethvin comment:4

resolution:	→ invalid
status:	new → closed

I'm pretty sure this has nothing to do with jQuery. You can see that serialize works fine if you alert out the lengths:

http://jsfiddle.net/dZfVH/5/

However, I have seen data truncation over the wire before, when developing an application that needed to send back large chunks of data via POST requests. Be sure your server is configured to handle large requests, I remember the old ASP.NET servers sometimes would reject posts over 100kb if not configured right. There was also one UK ISP that had some sort of problem with its network that would truncate post data silently when it got big. This was about four years ago so I don't recall all the details.

Our solution was to switch to JSON format and normalize the data because it had a lot of redundant values. That turned out to be easier on bandwidth and not a problem because the normalized data matched the backend SQL tables.

Anyway, good luck.

Side navigation