Issue 67565 in chromium: Error 324 (net::ERR_EMPTY_RESPONSE)

288 views
Skip to first unread message

chro...@googlecode.com

unread,
Dec 20, 2010, 10:59:38 AM12/20/10
to chromi...@chromium.org
Status: Unconfirmed
Owner: ----
Labels: Type-Bug Pri-2 Area-Undefined

New issue 67565 by evan.leonard: Error 324 (net::ERR_EMPTY_RESPONSE)
http://code.google.com/p/chromium/issues/detail?id=67565

Chrome Version : 8.0.552.231
URLs (if applicable) : any with SSL
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5: OK
Firefox 3.x: OK
IE 7/8:n/a

What steps will reproduce the problem?
1. Open Chrome
2. Navigate to a site requiring SSL (for instance an Atlassian Jira or
Confluence instance w/ SSL)
3. Observe 324 error

What is the expected result?


What happens instead?


Please provide any additional information below. Attach a screenshot if
possible.


chro...@googlecode.com

unread,
Dec 20, 2010, 11:07:47 AM12/20/10
to chromi...@chromium.org

Comment #1 on issue 67565 by evan.leonard: Error 324
(net::ERR_EMPTY_RESPONSE)
http://code.google.com/p/chromium/issues/detail?id=67565

Here's the results from using: chrome://net-internals/#tests on a failing
url

Result Experiment Error Time (ms)
FAIL Fetch https://wiki.<mycompany>.com/
Don't use any proxy
-324 424
FAIL Fetch https://wiki.progress.com/
Use system proxy settings
-324 538
FAIL Fetch https://wiki.progress.com/
Use Firefox's proxy settings
-324 454
Fetch https://wiki.progress.com/
Auto-detect proxy settings
? ?

chro...@googlecode.com

unread,
Dec 20, 2010, 11:23:30 AM12/20/10
to chromi...@chromium.org

Comment #2 on issue 67565 by evan.leonard: Error 324
(net::ERR_EMPTY_RESPONSE)
http://code.google.com/p/chromium/issues/detail?id=67565

Through a little investigation I found that if I start up like this with
the -use-system-ssl then everything works OK:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome
-psn_0_4547670 --flag-switches-begin -use-system-ssl --flag-switches-end

chro...@googlecode.com

unread,
Dec 21, 2010, 5:18:27 PM12/21/10
to chromi...@chromium.org

Comment #8 on issue 67565 by evan.leonard: Error 324
(net::ERR_EMPTY_RESPONSE)
http://code.google.com/p/chromium/issues/detail?id=67565

Here are the webserver details:

Apache: 2.0.63
Tomcat: 6.0.18
ClearSpace: 2.5.17
JRE: 1.6

Apparently Chrome 8.0.552.224 works with these apps, but the version of
Chrome I'm using (8.0.552.231) does not.

chro...@googlecode.com

unread,
Dec 22, 2010, 10:56:13 AM12/22/10
to chromi...@chromium.org

Comment #9 on issue 67565 by a...@chromium.org: Error 324
(net::ERR_EMPTY_RESPONSE)
http://code.google.com/p/chromium/issues/detail?id=67565

Apache with mod_ssl uses OpenSSL, which certainly doesn't have any issues
with False Start. Also, no changes to False Start (except to add
giltcdn.com to the blacklist) were made between 552.224 and 552.231.

Are you sure that it's really an Apache server which is terminating the
connections?

chro...@googlecode.com

unread,
Dec 23, 2010, 2:59:18 AM12/23/10
to chromi...@chromium.org

Comment #10 on issue 67565 by bugsy2...@gmail.com: Error 324
(net::ERR_EMPTY_RESPONSE)
http://code.google.com/p/chromium/issues/detail?id=67565

I'm having the same issue as well with https on my site. When I use
-use-system-ssl my site loads without a problem. Once I have the page
cached I can close the browser and start a new session without the switch
and the https page will load.

However, if I click on the icon in the address bar to see certificate
details I have this message "the connection had to be retried using ssl
3.0. this typically means that the server is using very old software and
may have other security issues"

If I clear cache, or refresh enough times, I once again cannot connect to
https.

I'm not sure if this is a server issue or a browser issue, but https will
load in all other browsers.

chro...@googlecode.com

unread,
Dec 23, 2010, 1:31:29 PM12/23/10
to chromi...@chromium.org

Comment #11 on issue 67565 by a...@chromium.org: Error 324
(net::ERR_EMPTY_RESPONSE)
http://code.google.com/p/chromium/issues/detail?id=67565

bugsy2334: what is the URL?

chro...@googlecode.com

unread,
Dec 23, 2010, 2:15:59 PM12/23/10
to chromi...@chromium.org

Comment #12 on issue 67565 by bugsy2...@gmail.com: Error 324
(net::ERR_EMPTY_RESPONSE)
http://code.google.com/p/chromium/issues/detail?id=67565

Can I send to you privately so it's not publicly shown?

chro...@googlecode.com

unread,
Dec 23, 2010, 2:52:40 PM12/23/10
to chromi...@chromium.org

Comment #13 on issue 67565 by a...@chromium.org: Error 324
(net::ERR_EMPTY_RESPONSE)
http://code.google.com/p/chromium/issues/detail?id=67565

bugsy2334: Of course you can always email private information and, if you
so desire, use http://www.imperialviolet.org/key.asc

chro...@googlecode.com

unread,
Jan 27, 2011, 6:47:43 PM1/27/11
to chromi...@chromium.org

Comment #22 on issue 67565 by a...@chromium.org: Error 324
(net::ERR_EMPTY_RESPONSE)
http://code.google.com/p/chromium/issues/detail?id=67565

ser...@bitpalast.de: the issue with FreeBSD, and the maintainers of the
FreeBSD port concur, is that your servers are miscomputed. You are linking
against a different major version of OpenSSL than you compiled against.
This is causing memory corruption in your servers and is probably an
exploitable issue.

chro...@googlecode.com

unread,
Jan 28, 2011, 12:32:48 AM1/28/11
to chromi...@chromium.org

Comment #23 on issue 67565 by serv...@bitpalast.de: Error 324
(net::ERR_EMPTY_RESPONSE)
http://code.google.com/p/chromium/issues/detail?id=67565

Given the reply: a) Why do other browsers work problem-free? b) If the
maintainers of the FreeBSD port concur, what are the exact steps to resolve
the problem on the FreeBSD platform?

We did of course test and re-compiled an Apache 2.2.17 and OpenSSL 1.0.0.4
last night, but the problem persists. What instructions or parameters need
to be given to resolve the problem?

chro...@googlecode.com

unread,
Jan 28, 2011, 6:27:21 AM1/28/11
to chromi...@chromium.org

Comment #25 on issue 67565 by serv...@bitpalast.de: Error 324
(net::ERR_EMPTY_RESPONSE)
http://code.google.com/p/chromium/issues/detail?id=67565

Thank you very much for your reply. I have escalated the issue to our
datacenter experts. I know you are doing your best in developing a great
browser. But anyway, in this specific case I would kindly like to ask you
to reconsider your decision. Here is my argumentation:

A) Consider hundreds of thousands of FreeBSD/Apache 2 installations out in
the market that will need to be re-compiled/re-installed. This will cause
hundreds of thousands of work hours and therefore will have a global
economic impact. This bug will also have serious implications on the use of
Chrome in many companies. It will limit the market share that Chrome can
reach. You can tell that from Evan's comment #16 already.

B) Then in comparison to this huge impact and negative impact on the
distribution and market share of Chrome think about the very small effort
it would take to add a simple if-then decision in Chrome, e.g.
if ((324 Empty Response) && (SSL connection)) {
[run same procedure again but omit false start];
}

Why wouldn't you as developers not want to add such a simple switch. It
appears to me to be a much better solution than maintaining black lists
that will soon increase to thousands of URLs. Please give this a second
thought. What was first? FreeBSD/Apache or Chrome? We here believe that a
new browser should be compatible to what's already in the market and not
that the whole world should update their it infrastructure to match a new
browser. I much hope that you take a minute to address this bug with a
work-around IN Chrome.

chro...@googlecode.com

unread,
Jan 29, 2011, 2:13:12 PM1/29/11
to chromi...@chromium.org

Comment #26 on issue 67565 by a...@chromium.org: Error 324
(net::ERR_EMPTY_RESPONSE)
http://code.google.com/p/chromium/issues/detail?id=67565

Firstly, your issue isn't related to False Start, it's TLS compression
which is causing you problems.

We know from experience that adding workarounds doesn't help: the problems
that get worked around don't get fixed. We are still dealing with servers
that can't correctly implement ten year old standards even today.

Additionally, we certainly wouldn't want to add a workaround for this. It
would just leave a landmine for anyone who wanted to use compression in the
future and we want server operators to know that something is wrong. The
FreeBSD issue makes it very easy to take down any affected server.
Additionally, it's likely to be an easy security exploit. Given that the
issue is apparently known, there's a possibility that servers are already
getting sequestered.

chro...@googlecode.com

unread,
Jan 29, 2011, 6:12:32 PM1/29/11
to chromi...@chromium.org

Comment #27 on issue 67565 by serv...@bitpalast.de: Error 324
(net::ERR_EMPTY_RESPONSE)
http://code.google.com/p/chromium/issues/detail?id=67565

I must have obviously understood comment #5 wrong. We tried the
--disable-ssl-false-start option, and with a disabled False Start SSL does
not cause any problems in Chrome. So I thought that an activated False
Start is the problem (no False Start = no problem).

Sorry to hear that you won't fix the issue. As for our customers I am sure
that they will rather prefer a solution that is a millisecond slower but
works in opposite to a super high tech up-to-date solution only one browser
with a very limited market share uses and does not work. I understand that
you wish the IT world to be perfect. From a practical point of view however
the goal should be to make things work.

chro...@googlecode.com

unread,
Jan 29, 2011, 6:24:38 PM1/29/11
to chromi...@chromium.org

Comment #28 on issue 67565 by a...@chromium.org: Error 324
(net::ERR_EMPTY_RESPONSE)
http://code.google.com/p/chromium/issues/detail?id=67565

This is nothing to do with False Start or speed (OpenSSL doesn't have any
issues with False Start). Disabling False Start may appear to solve the
issue, but that's because memory corruption can manifest in odd ways.

The problem is (again, probably, because I'm mostly guessing based on the
similarity with other case) that your Apache thinks that OpenSSL's data
structures are smaller than OpenSSL does. This means that Apache is
randomly corrupting its memory and crashing. Hiding this will only result
in the problem going unnoticed until someone malicious decides to use it in
order to steal all the private data from such servers and add them to a
botnet to DDoS someone else.

chro...@googlecode.com

unread,
Jan 31, 2011, 7:53:25 AM1/31/11
to chromi...@chromium.org

Comment #29 on issue 67565 by serv...@bitpalast.de: Error 324
(net::ERR_EMPTY_RESPONSE)
http://code.google.com/p/chromium/issues/detail?id=67565

For everyone out there, here is an easy solution to work around the Google
bug: deactivate mod_deflate in httpd.conf. That's it.

The bad part of it is, that your websites won't compress any more
afterwards, so you will need to decide whether to have a fast, compressed
delivery of files or make it work with Chrome.

chro...@googlecode.com

unread,
Mar 5, 2011, 12:01:34 PM3/5/11
to chromi...@chromium.org

Comment #30 on issue 67565 by j...@zebotech.com: Error 324
(net::ERR_EMPTY_RESPONSE)
http://code.google.com/p/chromium/issues/detail?id=67565

well, I tried disabling mod_deflate. It does not solve the issue. I do
happen to be running FreeBSD. Its a VPS system from ViaVerio. I'm not even
certain recompiling everything is an option. While I'm going to try doing
so, I agree with one of the other posters. This is Chrome's problem and
should be fixed in Chrome. To not do so is arrogant. I appreciate the
idea that you guys are trying to keep a well optimized browser, however it
is not up to you to force servers all over the world to recompile
everything or not work in chrome. The site I got this reported on is
alpinesports-santafe.com when in https mode only. The site works fine in
all the other major browsers. I'm not gonna hold my breath though for
Google to fix this.

chro...@googlecode.com

unread,
Mar 17, 2011, 3:19:59 AM3/17/11
to chromi...@chromium.org

Comment #31 on issue 67565 by endymion...@gmail.com: Error 324
(net::ERR_EMPTY_RESPONSE)
http://code.google.com/p/chromium/issues/detail?id=67565

Your mileage may vary, but on my Verio VPS, I disabled mod_deflate at the
top of the httpd.conf and then added the "LoadModule deflate_module
modules/mod_deflate.so" inside <Directory "/home/*/www">. This appeared to
do the trick for me and now Chrome shows the secure pages without error and
still gzip compressed apparently. Granted I have a shared certificate, so
all of my secure pages are routed from the /www/htdocs/ path and link back
to files contained in the /home/*/www path.

chro...@googlecode.com

unread,
Mar 26, 2011, 4:28:27 AM3/26/11
to chromi...@chromium.org

Comment #32 on issue 67565 by serv...@bitpalast.de: Error 324
(net::ERR_EMPTY_RESPONSE)
http://code.google.com/p/chromium/issues/detail?id=67565

@endymion: I confirm the workaround in comment #31 for the NTT/Verio VPSv3,
this workaround works.

chro...@googlecode.com

unread,
Apr 16, 2011, 12:41:15 PM4/16/11
to chromi...@chromium.org

Comment #35 on issue 67565 by I...@teamITS.com: Error 324
(net::ERR_EMPTY_RESPONSE)
http://code.google.com/p/chromium/issues/detail?id=67565

We also encountered this problem on some servers after Verio/ViaVerio
upgraded OpenSSL on their FreeBSD 6 servers (VPS and MPS) in late
October/early November. I just wanted to point out that a graceful restart
doesn't seem to resolve the issue after commenting out mod_deflate;
however, a full stop/start does.

The issue occurred for any SSL connection to the server (page, image, etc.)
and results in a "child pid 97236 exit signal Bus error (10)" message in
the main error_log file when the Apache process crashes.

chro...@googlecode.com

unread,
May 2, 2012, 10:04:06 AM5/2/12
to chromi...@chromium.org

Comment #36 on issue 67565 by sean.ait...@gmail.com: Error 324
(net::ERR_EMPTY_RESPONSE)
http://code.google.com/p/chromium/issues/detail?id=67565

I can't retrieve https://ajax.microsoft.com/ajax/jquery/jquery-1.4.2.min.js
because of this. That's a pretty high profile URL used by many ASP.NET web
sites. Interestingly, the problem doesn't exist on the Mac OSX version of
Chrome. Why has this been marked as WontFix? It took me a very long time to
figure out what was causing the problems I was seeing.

chro...@googlecode.com

unread,
May 2, 2012, 10:46:10 AM5/2/12
to chromi...@chromium.org

Comment #37 on issue 67565 by a...@chromium.org: Error 324
(net::ERR_EMPTY_RESPONSE)
http://code.google.com/p/chromium/issues/detail?id=67565

sean.aitken: there were two issues mixed in here. One was that FreeBSD
machines that are running Apache against OpenSSL 1.0.0, but which compiled
against 0.9.8 will crash because the ABIs aren't compatible.

The second was a general False Start intolerance problem.

The first doesn't appear to be the case as
https://ajax.microsoft.com/ajax/jquery/jquery-1.4.2.min.js is working fine
for me and the FreeBSD issue causes problems quite consistently.

The second doesn't appear to be the case either: I don't observe any
problems loading that URL with both False Start and 1/n-1 record splitting
in 50 trials.

chro...@googlecode.com

unread,
May 2, 2012, 11:10:28 AM5/2/12
to chromi...@chromium.org

Comment #38 on issue 67565 by sean.ait...@gmail.com: Error 324
(net::ERR_EMPTY_RESPONSE)
http://code.google.com/p/chromium/issues/detail?id=67565

I see the two issues overlapping, and I'm definitely talking about the
(arguable) issue in Chrome, the latter of the two. I am behind a firewall
and the symptoms are the same. I hit that URL, and after a minute or so I
get the ERR_EMPTY_RESPONSE. When I modify my Chrome shortcut and add this:
--flag-switches-begin --disable-ssl-false-start --flag-switches-end
The problem goes away and I can hit that URL with no problems. Maybe it's
just strange coincidence? Maybe the firewall is affecting things also?
Still, at the end of the day, everyone else using IE or Firefox has no
problems. I have to add this command line switch to overcome the problem. I
just can't accept that this is a problem that wont be fixed.
Also, the shortcut modification works okay, but if you invoke the browser
through a link in an email or other means, that shortcut gets circumvented
and all browser instances spawned thereafter will exhibit the problems with
some SSL URL's.
Fix it or not, I thought this would be helpful. Let me know if I can
provide any more information that can help.

chro...@googlecode.com

unread,
May 2, 2012, 11:45:10 AM5/2/12
to chromi...@chromium.org

Comment #39 on issue 67565 by a...@chromium.org: Error 324
(net::ERR_EMPTY_RESPONSE)
http://code.google.com/p/chromium/issues/detail?id=67565

sean.aitken: Do you see a repeatable, clear failure when connecting to that
site? As mentioned, I can't find a fault with the site itself. The firewall
could well be the cause of the problem, although it's not clear why it
would be affecting that HTTPS site in particular.

However, the good news (from your point of view) is that the triggering
conditions for False Start will be significantly tightened with Chrome 20
to avoid these sorts of issues. We'll be using an opt-in, rather than
opt-out scheme and, at the moment, Google sites are the only ones that I
know of that meet the new triggering conditions. (Although others are
working on it.)

chro...@googlecode.com

unread,
May 2, 2012, 11:59:02 AM5/2/12
to chromi...@chromium.org

Comment #40 on issue 67565 by sean.ait...@gmail.com: Error 324
(net::ERR_EMPTY_RESPONSE)
http://code.google.com/p/chromium/issues/detail?id=67565

That's good to know, fur sure!! I'll do some tests at home tonight. I'm
kinda thinking that if the URL is loading fine for you that the firewall
has something to do with it. It's definitely repeatable for me. Every
attempt fails. I'll try and gather more information about the firewall and
anything else that's relevent. I'll post anything useful. Even if it's
changing to be an opt-in model, it would be nice to have the problem fixed,
whether it's in the firewall or Chrome. Thanks for the help!!

chro...@googlecode.com

unread,
Jun 29, 2012, 10:35:33 AM6/29/12
to chromi...@chromium.org

Comment #41 on issue 67565 by scal...@msn.com: Error 324
(net::ERR_EMPTY_RESPONSE)
http://code.google.com/p/chromium/issues/detail?id=67565

I am having the same issue as described by Sean. If I try to get
https://ajax.microsoft.com/ajax/3.5/MicrosoftAjax.js then I get
ERR_EMPTY_RESPONSE however if I get it through HTTP then no problem.

chro...@googlecode.com

unread,
Jun 29, 2012, 10:38:34 AM6/29/12
to chromi...@chromium.org

Comment #42 on issue 67565 by a...@chromium.org: Error 324
(net::ERR_EMPTY_RESPONSE)
http://code.google.com/p/chromium/issues/detail?id=67565

scalius: https://ajax.microsoft.com/ajax/3.5/MicrosoftAjax.js works fine
for me so I'm afraid it's probably a proxy or such near you that's
misbehaving. A net-internals dump might help clarify if you can provide
one:
https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

Reply all
Reply to author
Forward
0 new messages