0

I am posting a large amount of data. I need this to be as small as possible for performance reasons.

My data starts out as JS objects. I then stringify it using json. I then send it in a post.

The thing is that I have a lot of objects:lists [] and dict {}, as well as short texts, which are placed in quotes "" by json.

These are then uri encoded before being posted. I do not do this; the browser does it. I can see the result when I look in the request body.

So, every [, {, and "" is now uri encoded, meaning that my string becomes much longer. In fact, if I compare

 alert(          JSON_local.stringify(myStuff).length);
    alert(encodeURI(JSON_local.stringify(myStuff).length);

the uri encoded string is 50% larger. That's a lot bigger when the string starts out big.

Am I missing something here? json is standard, but it seems to have a negative side effect for me. is there an alternative to using json? Or am I doing something wrong here? Data alsways has to be send as uri encoded, no?

BhavikKama
  • 8,566
  • 12
  • 94
  • 164
user984003
  • 28,050
  • 64
  • 189
  • 285
  • what about compressing the data? See more discussion [here](http://stackoverflow.com/questions/8102824/how-to-zip-gzip-user-data-in-javascript-before-sending-to-the-server). It should be an easy way to reduce the amount of data sent, without sacrificing the good sides of JSON. – eis Sep 03 '13 at 07:35
  • I've tried https://code.google.com/p/jslzjb/. It has almost no effect. – user984003 Sep 03 '13 at 07:36
  • The compression issue seems to be that the compressed data includes a lot of commas which also take up a lot of space as %2C – user984003 Sep 03 '13 at 07:45

1 Answers1

1

Data always has to be send as uri encoded, no?

Not true. This depends on the content type you're sending it.

If you use x-www-form-urlencoded content-type when sending it, you need to encode the data. If you use multipart/form-data, for example, you do not need to. This has been discussed in more length in here. For considerable amount of data, I don't see any real reason to use x-www-form-urlencoded.

Of course, there is more to it than just changing the content type, you need to supply the mime boundaries then. It does sound to me however that that'd be more efficient for you. From http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4:

The content type "application/x-www-form-urlencoded" is inefficient for sending large quantities of binary data or text containing non-ASCII characters. The content type "multipart/form-data" should be used for submitting forms that contain files, non-ASCII data, and binary data.

Community
  • 1
  • 1
eis
  • 51,991
  • 13
  • 150
  • 199
  • That made it 30% faster. Thanks! Now I may also be able to take advantage of compression, which was giving me a lot of commas. – user984003 Sep 03 '13 at 09:50