Request URI Too Long

Jan 14, 2010 at 9:52 PM

I am wondering if anyone has run into this issue where the serialized request that is being sent is too long? If so I am wondering how you dealt with it.

For now I have updated the latest revision in trunk to support sending data through an HTTP POST rather than the default GET. I added a config value entry called MethodType that will allow you to set whether you are using GET or POST. The default is still GET if you don't specify.

If you have a better way please let me know what I could have done to work around this.



Jan 15, 2010 at 4:23 AM
Edited Jan 15, 2010 at 4:25 AM

Hi Sergio,

Thanks for the heads-up.

Actually I've run into a URI too large error in the generateText() & inlineCss() methods, but not elsewhere -- which is why I put the notes in the documentation that those methods should not use serial requests, but use xml-rpc.

In what method did you get the error?

Changing the request from a GET to a POST had no effect for me, because the URI length is the same regardless of GET/POST method and the MC server rejected it in both cases -- my request length was in the 40k+ range.

Thanks for bringing this up though, I had thought about changing the method at one time a while back & completely forgot about it. I prefer using POST anyway, it was just an oversight.

I am changing the method to POST for the 'final' v1.2.2 version -- it's a simple 1 line change in the apiHelper.SerialRequestResponse() method to add the line


wRequest.Method = "POST"; 


I can't think of a real good reason off-hand to not just change the method to a POST and not worry about a MethodType parameter, other than the always popular 'choice' reason.

Anybody else have any thoughts?


FYI:  I'm delaying the final v1.2.2 version until Monday the 18th -- between some refactoring I'm doing on the Validator() & ValidateInput() classes & client work, I need the weekend to finish testing & tweaking.

I'll put a note up tomorrow with the schedule change & notes.



Jan 15, 2010 at 4:32 AM
Like you said I just put the methodtype there for choice and some may want to keep their requests simple and just use GET. Honestly if I didn't have this problem I wouldn't have even consider changing. Anyways the method I was having problems with was createcampaign because we are storing all of our html information on our side and then sending to mailchimp when we are going to send. So I have to send all of that content and it ends up in the url which makes it too long.

The change you are talking about making is easy enough to change the method from get to post but it wouldn't have solved this problem because the uri being sent is still too long. So the other reason for the methodtype is it toggles between sending all data in the url with the get or just appending the method name only to the url and all other parameters I but into the body of the request using the standard var1=value1&var2=value2 format. This allows me to pass my large blocks of content in the body of the request rather than the url and thus fix the problem that I am having. If you want I can send you the changes that I made as I had to alter every method to change what parameters are sent into the requestbuilder in your apihelper.

So anyways it is working great for us and there are no problems with the change.

Thanks again for all the hard work on the library it was a great starting point to get our application working quicker.

Jan 15, 2010 at 5:06 AM

Doh. Of course, that makes sense -- it's what happens when I try to think this late at night. Garbage comes out.

I would like you to email me a sample of the changes you made -- I think that I would like to make that an option for a future version.  Probably not v1.2.3 -- i want to get that out fairly quick after this one on Monday -- but the next one after.

If I think about it some, I think (hope) I should be able to change the requestbuilder routines to minimize the change impact on the individual methods by changing what the request/response statements build or do when calling the apihelper based on the method type.  But that's for thinking about on another day when I'm not so brain-fried.

Thanks again,


Jan 15, 2010 at 5:18 AM
Sure. I would be glad to contribute back something David. I will zip up the directory and send it over to you. I didn't update the UI project just the library. Where do you want me to send the changes to?