After a load of hard work developing a site, and learning to use EE, I thought I had it all together until I kept getting this message when trying to download a file from my site that I had uploaded when I published a post from the EE CP.

___________________
error message 413:
Request Entity Too Large
The requested resource
/ee/index.php
does not allow request data with GET requests, or the amount of data provided in the request exceeds the capacity limit.
____________________________

After reading this post from last year, I learned the problem was actually with my webhost: http://expressionengine.com/forums/viewthread/67687/

So, I contacted them asking if they would remove the no “url=http” rule they have in place on their server, the way they did for their other customer in the above post.

So far, they aren’t budging on the rule. I’ve tried asking a second time, and am waiting for their response.

In the interim, I was wondering if anyone knew of any workarounds I could implement?

Thanks for any help!

Hi, kyneburg, welcome to the forums!

As you can see from that post, there is really not much that we are able to do from this end; the rule needs to be lifted by your host.  Both our CEO and one of our Technology Architects responded with explanations in the thread you linked to.

I wish we could help more, but in this case there is not much that can be done.

kyneburg - 01 December 2008 04:33 PM

So, I contacted them asking if they would remove the no “url=http” rule they have in place on their server, the way they did for their other customer in the above post.

So far, they aren’t budging on the rule. I’ve tried asking a second time, and am waiting for their response.

Who is the host?

It’s always good to know who to avoid.

Unfortunately, the news from my webhost provider is that they cannot make an exception the no “url=http” rule, even though they did it a year ago for someone else.

This is the reply I received: “We haven’t blocked this apache pattern because of security hole in CMS Expression Engine or any specific software. It has been blocked due to its high security risk and several script injections through this pattern which we have faced before. Unfortunately, we cannot remove this rule. Try to change the configuration of your script to use a different pattern such as “u=http”.”

And that was why I asked earlier if there was any way I could “work-around” the original EE script in my previous post. A friend of mine suggested such a thing would be possible, and so does the webhost provider, but I don’t know enough about such things to just peer into the code and make the correct changes. Nor do I want to extend my efforts in learning scripts too now, since my project timeline is pressing. So I’m just going to put EE on the backburner until I can dedicate some time to figure out how to do it.

As for my web-host provider, Canaca-com, they are an excellent company in every respect, other than this seemingly extreme concern for security (for better or worse). I’m going to stick with them because I’ve invested too much at this point; they do have very competitive rates, professional and efficient support, and they throw freebies my way too.

Thanks for the feedback!

kyneburg - 02 December 2008 12:07 PM

Unfortunately, the news from my webhost provider is that they cannot make an exception the no “url=http” rule, even though they did it a year ago for someone else.

I am afraid there really is not very much we can do about it right now.

It has been blocked due to its high security risk and several script injections through this pattern which we have faced before.

To be honest, I consider this an overreaction on part of the host. It might be fine as a default configuration, but not letting a customer who obviously knows what he’s doing override this I find personally unacceptable.

And that was why I asked earlier if there was any way I could “work-around” the original EE script in my previous post.

I am not aware of a workaround at this point. Your best bet would probably be a feature request to change certain aspects of EE in this regard. We certainly do not recommend that you hack EE.

So I’m just going to put EE on the backburner until I can dedicate some time to figure out how to do it.

That’s very unfortunate, of course. Personally, I’d seriously consider changing hosts.