Performance Zone is brought to you in partnership with:

Raymond Camden is a developer evangelist for Adobe. His work focuses on web standards, mobile development and Cold Fusion. He's a published author and presents at conferences and user groups on a variety of topics. He is the happily married proud father of three kids and is somewhat of a Star Wars nut. Raymond can be reached via his blog at www.raymondcamden.com or via email at raymondcamden@gmail.com Raymond is a DZone MVB and is not an employee of DZone and has posted 213 posts at DZone. You can read more from them at their website. View Full User Profile

Sending Data to the Server with HTTP? Size Matters

11.07.2012
| 2966 views |
  • submit to reddit

A few times a month I run into someone having issues with this and just a few minutes ago I helped someone out so I thought I'd write something up quickly to help make it (hopefully) a bit more Google-friendly for those having trouble.

The problem, and solution, is typically pretty simple. If you have found that your network calls to send data to the server are failing, check to see if you are doing a GET request. While according to Stack Overflow there is no real limit to the size of a GET request, there are practical and browser-specific limits that may impact you.

In general, if I'm building a form with a text area, I'll use a POST instead of a GET. If I'm sending a file than I'm definitely using POST.

To be clear, this isn't an "Ajax" issue, but a HTTP thing. The person who emailed me today was actually using the HTTPService in Flex.

I'll also add - it's probably a good idea to really think about how much data your user is sending to your server. Are there things you can do to minimize the size? Are you handling timeouts or other errors? On the server, are you checking how much free space you have available? Have you considered using S3 to bypass artificial limits on storage?

Published at DZone with permission of Raymond Camden, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)