Here’s Godaddy’s response to my inquiries. They’ve been somewhat helpful after I pointed out that the error is due to their new security rules. I still get the error, but much less often after they’ve switched me to Managed WordPress hosting. I am posting this for anyone else that gets this error in the future. Moderator – maybe you should consider moving the Empty_Response posts to their own thread? Thanks.

Dear Sir or Madam,

I am a member of Hosting Support, contacting you in regard to “err_empty response” error message you’ve been encountering intermittently when working on your WordPress site.

These errors on Linux Web Hosting accounts are due to MOD_SEC rules on our servers. The system relies on sets of scoring parameters to detect automation and spam. Repeated actions (i.e. excessive logins) from the exact same client to the same site will generally be the trigger. Over time though, this gets auto-unblocked.

Here are a few other reasons as to why you may be encountering the Connection Reset error:

1. You may have a malware/virus that is saved somewhere on the computer, possibly a tracking cookie.
Solution: You may want to run a scanner to review your computer for any malware or virus.

2. Local robots cache/cookie signatures can get their IP temporarily blacklisted.
Solution: Please clear your browser’s cache & cookies or try a Private Browsing session.

3. A cache/cookie from a previous login, causes the user will continue to try the login over and over.
Solution: Please clear your browser’s cache & cookies or try a Private Browsing session.

4. A saved cache/cookie data could attempt a POST to login over and over.
Solution: Please clear your browser’s cache & cookies or try a Private Browsing session.

5. Review scripts to ensure repeated rapid POST/GET requests are not being made.

There are two types of requests – one is a POST request and the second is a GET request. A POST request is used to send your data through the internet and network sources to a visitor’s computer. During this process, a POST request may “post” information in multiple places, such as your WordPress administrative panel, the WordPress database, and your local computer’s cache. Each one of these posts equals one HTTP request. The following information further details POST requests:

POST requests are never cached
POST requests do not remain in the browser history
POST requests cannot be bookmarked
POST requests have no restrictions on data length

The second HTTP request is a GET request, which is the request sent to your WordPress content from each visitor, search engine, or social media option such as Twitter, Facebook, or similar. If you have 10 visitors attempting to view the website via Facebook or directly entering the URL into a browser, you have 10 HTTP requests, which are operating at the same time as POST requests and all converging on the same WordPress content and database. Please note, GET requests are where you may be exceeding the HTTP requests and the following details the GET requests:

GET requests can be cached
GET requests remain in the browser history
GET requests can be bookmarked
GET requests should never be used when dealing with sensitive data
GET requests have length restrictions
GET requests should be used only to retrieve data

The following table lists some other HTTP request methods:

Method Description
HEAD Same as GET but returns only HTTP headers and no document body
PUT Uploads a representation of the specified URI
DELETE Deletes the specified resource
OPTIONS Returns the HTTP methods that the server supports
CONNECT Converts the request connection to a transparent TCP/IP tunnel

The following table compares the two HTTP methods: GET and POST.

GET POST
BACK button/Reload Harmless Data will be re-submitted (the browser should alert the user that the data are about to be re-submitted)
Bookmarked Can be bookmarked Cannot be bookmarked
Cached Can be cached Not cached
Encoding type application/x-www-form-urlencoded application/x-www-form-urlencoded or multipart/form-data. Use multipart encoding for binary data
History Parameters remain in browser history Parameters are not saved in browser history
Restrictions on data length Yes, when sending data, the GET method adds the data to the URL; and the length of a URL is limited (maximum URL length is 2048 characters) No restrictions
Restrictions on data type Only ASCII characters allowed No restrictions. Binary data is also allowed
Security GET is less secure compared to POST because data sent is part of the URL

Never use GET when sending passwords or other sensitive information! POST is a little safer than GET because the parameters are not stored in browser history or in web server logs
Visibility Data is visible to everyone in the URL Data is not displayed in the URL

Please let us know if we can assist you in any other way.

Update: Godaddy moved me from CPanel to Managed WordPress Hosting because, after 2×2 hour phone calls they couldn’t tell what was happening. I will keep you posted if this solves the problem or not, for your future reference. Sorry about all the ruckus ;)

Hey Ismael,

Yes, I have contacted Godaddy. They’re saying that something is heavily using the I/O resources and I have to figure out what that is, before the website will function properly. I have read that other people have issues with their IP getting temporarily blocked, because it makes too many requests and a solution would be contacting the provider and whitelisting the IP. I have told them so, but they pointed out that something or multiple somethings is/are generating a lot of traffic for my I/O to spike up like that. I have seen it myself, when I try to edit or save a page, my I/O jumps at 2 MB/s, which is the highest resource plan for hosting. So, they are saying that even if they whitelist my IP, it will automatically get banned again the next time when the disk usage spikes up.

This only seems to happen when I edit/save a page. If I take down all the plugins, it does work, although there is no particular plugin that causes the problem.

So, is there anything that can be done. And, this maybe a stupid question, but is there a plugin/way to slow down or change how the requests to the server are made when editing pages?

Thanks,
Silviu

Here is a quick update, for those who might run into this in the future. This does work. However, if you have too many events(I had 42 – to track each individual element, such as buttons, images and text links, on 3 different pages) it might get your IP temporarily banned with your provider. When this happens to me, I get a “ERR_EMPTY_RESPONSE” message and I can’t access the site for 2-3 minutes. This makes it impossible to even edit a page. I read that it might be because I am with GoDaddy and they limit the number of post requests for security reasons.

After turning off all the plugins and uploading a fresh copy of the theme, I started removing the snippets that I added to the theme files and this javascript (unfortunately) turned out to be what was causing the problem.

Is it possible to do it differently, or do I just have to limit the number of events that I am tracking?

I will consider it. I’m sorry if I abused your free service. I hoped this would be beneficial for all of us; gray logos as a trust element seem to be the norm nowadays(as to provide the user with more reasons to trust without distracting attention from the page’s main goal/call to action).

Regards,
Silviu