New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 18 users

Issue metadata

Status: WontFix
Owner:
User never visited
Closed: Nov 2009
Cc:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: ----
Type: Bug

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment

Unable to search google via find bar or google.com (intermittent)

Reported by rofl%cri...@gtempaccount.com, Oct 8 2009

Issue description

Chrome Version       : 4.0.221.8-r28108
OS + version : Ubuntu 9.04
CPU architecture (32-bit / 64-bit): 64-bit
window manager : Gnome
URLs (if applicable) : http://www.google.com
Behavior in Firefox 3.x (if applicable): Works as expected
Behavior in Chrome for Windows (optional):

What steps will reproduce the problem?
1. Do repeated searches from the find bar, especially after using Chrome
for a while.
2. When it breaks, it should also not work when searching via
http://www.google.com either


What is the expected result?

Search results.


What happens instead?

One of two errors.  Sometimes you get this page:

  This webpage is not available.

  The webpage at http://www.google.com/search?aq=f&sourceid=chrome&ie=UTF-
8&q=meh might be temporarily down or it may have moved permanently to a new
web address.

  More information on this error
    Below is the original error message

      Error 330 (net::ERR_CONTENT_DECODING_FAILED): Unknown error.


Other times, you'll get the google search results page, but only the first
result is returned.



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

I have seen the same behavior on both my laptop and work machine, which are
both Ubuntu 9.04 64-bit, with the last chromium package from the apt
repository.

 

Comment 2 by tomcj...@gmail.com, Oct 9 2009

+2

Both myself and a colleague at work are experiencing this problem although on the
infrequent when it does return the google search results we see all of the results
and not just the first result as for the original poster.

We are running Ubuntu 9.04 64-bit - Chromium 4.0.222.1 (Ubuntu build 28248).

Comment 3 by tomcj...@gmail.com, Oct 9 2009

Oh, and sorry should have mentioned.  We are both running the Privoxy proxy to filter
out ads.

Problem only occurs when running through privoxy, when run with direct connection to
the internet search works fine.
I'm also using Privoxy.  I didn't think to include this in my initial report, but it 
apparently does something that intermittently breaks Chromium.
FYI-updated to Chromium 4.0.222.5 and I'm still experiencing the same behavior.  I 
briefly looked at the config and can't seem to figure out what's breaking chromium, 
but something definitely is.
I did a little investigating, and the problem appears to be related to SDCH encoding.  
I saw in another bug report that some proxies can crap up a SDCH encoded page, so I 
tried adding "--enable-sdch=nothing" on the command-line, and everything works.  I'm 
not sure where to go from here, but that appears to be a valid workaround.

Comment 7 by wtc@chromium.org, Oct 16 2009

jar: this bug seems to be caused by SDCH encoding.

Comment 8 by jar@chromium.org, Oct 16 2009

Status: Assigned
SDCH (which stands for Shared Dictionary Compression over HTTP) can indeed be 
impacted by mis-behaving proxies.  The system tries to recover gracefully, 
transparently inducing a meta-refresh in the face of such network corruption(?).

To better diagnose the problem, it would be most helpful to be sure to include what 
proxy you believe you are going through, as well as some details from a corrupted 
page.  Specifically, when you get a corrupted page, you should prepend the following 
string to the URL:

about:cache/

and press enter.  Please at least copy the header section of that page into this bug.  
If the content is still very confusing, I may ask for a copy of the entire page 
(including the lower section, which provides the actual hex dump of the body of the 
page).

Also, for each person contributing to this bug report, please be sure to indicate 
exactly what version of Chromium is being used, as well as your platform.  If you're 
not sure what proxies you are going through, please try to indicate what ISP you're 
connecting to the internet with, as that has sometimes proved significant.

Thanks,

Jim

p.s., Some items mentioned, such as "unable to reach http://www.google.com/...." may 
relate more to a network problem than to SDCH related corruption.
  

Comment 9 by dvy12...@gmail.com, Oct 16 2009

I use Privoxy and pac autoconfig script to filter out script and ad every day, Privoxy alter html page for filtering something,if SDCH page was altered, Chromium analyse SDCH 
response maybe fail.

adding 

{ -filter }
www.google.com

to your Privoxy action file can resolve this problem !

Comment 10 by jar@chromium.org, Oct 16 2009

dvy12345: Just so I can understand more clearly what you proxy does: Am I correct 
that it actually modified content, to try to strip advertisements from within a page, 
and not just block URL fetches made for ads?

If I understand you correctly, it would certainly be plausible for such a "proxy" (I 
have to use that term loosely, given that it modifies content) would corrupt a page.  
It might un-gzip a file, and try to edit the content, and not realize that the 
content is also compressed by the second "sdch" compression :-(.  This would be 
kindred of scanning a raw gzip file, and pulling out strings of text, and then 
passing the result along as though it were still a gzip file :-(.

Please confirm my understanding.  If so, I would strongly suggest you file a bug 
against privoxy.  I would suspect that they are not properly processing the content-
encoding header, which asserts "gzip,sdch" compression was applied.

Comment 11 by tomcj...@gmail.com, Nov 12 2009

I am confident this is an issue with privoxy simply because I find that all browsers
I have tried through privoxy have suffered from this problem and just using Chromium
with a direct connection to the internet does not exhibit the behaviour.

If you want to continue running privoxy I recommend upgrading to 3.0.15 (beta).  I
was previously running 3.0.13-1 packaged with Ubuntu 9.10 but removing this packed
version and downloading and compiling the 3.0.15 (beta) from source seems to have
resolved the issue for me.

Comment 12 by jar@chromium.org, Nov 12 2009

Status: WontFix
Based on comments from tomcjohn, this issue is being resolved by upgrading to a newer 
version of privoxy.  ... and I'm marking this Won't Fix.

If the upgrade does not solve the problem, please re-open this bug, and possibly also 
list the corresponding privoxy bug so that I can track its progress, get compatibility 
info, and consider alternatives.

Thanks

Comment 13 by Deleted ...@, Nov 22 2009

another workaround is to use bing. 
then you dont have to give up the ad filtering or maintain your own privoxy package


Comment 14 by Deleted ...@, Dec 5 2009

I have chromium 4.0.263.0 (Ubuntu build 33682) and privoxy 3.0.13 (Ubuntu amd64).
Chromium displays the problem described here. Firefox doesn't. My status:
WontUseChromium.

Comment 15 by jar@chromium.org, Dec 5 2009

Labels: Saracenim
@SaraceniM:  Are you also using privoxy?  If so, can you also confirm your running with 
a version prior to 3.0.15, which was reported by tomcjohn to have caused this 
corruption?

Thanks,

Jim

Comment 16 by Deleted ...@, Dec 9 2009

i can also confirm this issue is present on google chrome 4.0.249.22 running on ubuntu 
9.10 32-bit with privoxy 3.0.13

it seems a bit difficult to reproduce, as the error doesn't happen very consistently. 
restarting the privoxy service doesn't seem to change this either. 

Comment 17 by apow...@gmail.com, Jan 4 2010

I can confirm this behaviour on the Windows versions as well.

Chrome: 4.0.266.0
Privoxy: 3.0.15

Privoxy was run as shipped.  Firefox 3.5.7 works as expected.

Comment 18 by Deleted ...@, Jan 30 2010

I'm running Debian Lenny (503) with Chrome 4.0.249.43 (Official Build 34537) and 
Privoxy 3.0.9. I keep my system on the stable branch whenever possible, hence the 
older Privoxy revision. dvy12...@gmail.com's suggested fix works for me: 

# Google fix? 
{-filter \
}
google.com
www.google.com

Comment 19 by Deleted ...@, Feb 6 2010

Have the same problem running Chromium 5.0.319.0 (38290) Ubuntu and Privoxy 3.0.13
also modifying the default.action did not solve the problem

Comment 20 by jar@chromium.org, Feb 6 2010

Here is the explanation of the privoxy bug, along with a work-around if you have to 
use privoxy (prior to their fixing of their bug)

The cause of the problem is that privoxy is reaching into content that is compressed, 
and removing data, resulting in a very corrupt stream.  Privoxy should instead honor 
the content encoding, and if it does not understand the encoding (in this case, 
content-encoding=gzip,sdch) then it should NOT alter the stream.  That is the current 
bug in privoxy.

If privoxy wants to be able to alter the stream, but does not understand SDCH, it can 
alternatively make sure that the stream is not SDCH compressed. To do so, privoxy 
should modify the outbound request to remove the "sdch" from the header line for 
"ACCEPT-ENCODING."  If privoxy did that, then the servers would not send SDCH encoded 
content.

It is always possible for a problematic proxy to corrupt a data stream, and that is 
what privoxy is currently doing.  I'd suggest either filing a bug with privoxy, 
and/or avoiding use of the privoxy product until it has repaired this bug.

As a work-around, in Chrome, you can disable this higher-performance compression 
encoding that it support.  To do so, you should use a command line option of:

--enable-sdch="nothing"

You will of course not get the benefits of SDCH compression, but at least you will be 
able to work with around this bug in privoxy.

Comment 21 by jar@chromium.org, Mar 11 2010

 Issue 37777  has been merged into this issue.
Hi all,
I've been encountering the same issue with Chrome and Privoxy. Here's a privoxy filter I just built to disable SDHC:

---[user.filters]---
CLIENT-HEADER-FILTER: no-sdhc Remove SDHC support

# Strip SDHC from Accept-Encoding headers.
s|^(Accept-Encoding:)\s*(.*,)sdhc(|,(.*))\s*$|$1 $2$4|i
s|^(Accept-Encoding:)\s*sdhc,(.*)\s*$|$1 $2|i
s|^(Accept-Encoding:)\s*sdhc\s*$||i

# Remove Avail-Dictionary
s|^Avail-Dictionary:.*$||i

# Remove X-SDHC attribute
s|^X-SDHC:.*$||i

SERVER-HEADER-FILTER: no-sdhc-server Remove SDHC support (server side)
# Remove Get-Dictionary
s|^Get-Dictionary:.*$||i

---[user.action]---
## apply sdhc stripping to any site, since it won't work with privoxy
{ +client-header-filter{no-sdhc} +server-header-filter{no-sdhc-server} }
/

--- ><8 --- ><8 --- ><8 ---

With these filters, I can access Google search again!

Anyone up for submitting them to the privoxy people? I'm feeling lazy today.
I'm experiencing the same problem, running tinyproxy on ubuntu 10.04 server edition.

Comment 24 by jar@chromium.org, Aug 12 2010

@scheepers:

This bug related to Privoxy, which damages content without due care about the content encoding.

Unless your "tinyproxy" is also doing such filtering, it should be an unrelated issue.  There was a bug in the tip-of-tree recently, so if you're not using a version built after Monday evening, you may encounter troubles (and should update your tree, or get a newer canary build, etc.)
FYI: I'm still seeing these problems, running ubuntu 10.10's privoxy 3.0.16-1 with Chrome 8.0.552.237.

I've just added the filter given in comment #22 to my privoxy configuration.  Although I don't know of any way to reliably reproduce this issue, I did do a bunch of google searches without this problem occurring.  I will post a follow-up comment here if I do have issues even with those filters enabled.

Comment 26 by jar@chromium.org, Jan 16 2011

I can't truly read the details of the privoxy filter, but I can guestimate the impact, and it should (if my guess is correct) disable SDCH at numerous levels.

Stripping the "sdch," from the "Accept-Encoding" will mean that the server will never be told to provide an sdch encoding, or even ask the client to get a dictionary fro such.

Stripping the server provided "Get-dictionary" would prevent an overly aggressive server from suggesting to the client that a dictionary be downloaded in the background, for potentially future use.  The server shouldn't typically suggest such without the accept-encoding line, but this extra stripping would block it in case it "decided" that Chromium supports this compression, so why not suggest a dictionary?  Note that some servers will for instance supply gzip, even when accept-encoding does not explicitly support such, as all modern browsers do support this compression.  This stripping future-proofs the privoxy filter against such aggressions (the client will never hear about a suggestion for a dictionary, and hence will never download one).

Stripping the "Avail-dictionary" line will prevent a client from advertising that it has a dictionary.  In Chromium's case, dictionaries are not cached (as dictionaries) from session to session, so it is hard to imagine, given the other filters, that Chromium would advertise a dictionary... but this privoxy patch seems very thorough.  Since the client can't advertise ownership of a dictionary, it is seemingly impossible for a server to guess about possession of a dictionary, so a server can't provide content encoded via SDCH <whew!!>.  Although there are currently no pre-baked dictionaries (dictionaries bulit in at compile time, and no dynamically loaded in the field?), this extra stripping future proofs a future client from advertising even pre-baked dictionaries.

bottom line: Any one of the filter lines, if they perform as I'd naively expect, should very aggressively prevent servers from using the SDCH compression protocol, and allow privoxy to then more freely ravage the stream, without destroying the content (as it currently does).  Using them all seems to future proof said effort.



The filter given in comment #22 transposes two characters of the expected Content-Encoding: it consistently uses "sdhc" instead of the correct "sdch".  The "Avail-dictionary" line by itself is sufficient to prevent the server from sending SDCH-encoded content, as jar pointed out in comment #26; the other elements of the filter have no effect because of the typo.  Please replace "sdhc" with "sdch".
I've realized that privoxy is registering an error with the filters as given in comment #22.  I don't know the protocol, so I'm not sure what it should be, but I'm currently using this for `/etc/privoxy/sdch.filter`:

    CLIENT-HEADER-FILTER: no-sdch Remove SDCH support
    
      # Strip SDCH from Accept-Encoding headers.
      s|^(Accept-Encoding:)\s*(.*,)sdch(\|,(.*))\s*$|$1 $2$4|i
      s|^(Accept-Encoding:)\s*sdch,(.*)\s*$|$1 $2|i
      s|^(Accept-Encoding:)\s*sdch\s*$||i
    
      # Remove Avail-Dictionary
      s|^Avail-Dictionary:.*$||i
    
      # Remove X-SDCH attribute
      s|^X-SDCH:.*$||i
    
    SERVER-HEADER-FILTER: no-sdch-server Remove SDCH support (server side)
    
      # Remove Get-Dictionary
      s|^Get-Dictionary:.*$||i

The only difference other than replacing "shdc" with "sdch" is that the second `|` in the first `s|...` directive is backslash-escaped.

My `/etc/privoxy/sdch.action`:

    { +client-header-filter{no-sdch} +server-header-filter{no-sdch-server} }
    /

And I've added these lines separately, near similar ones, in `/etc/privoxy/config`:

    actionsfile sdch.action      # Workaround for issues with SDCH compression in Chrome.

    filterfile sdch.filter       # Workaround for issues with SDCH compression in Chrome.

So this config avoids errors being logged (with `debug 12288` in `/etc/privoxy/config`) and seems to work so far.

Comment 29 by Deleted ...@, Apr 24 2011

Can someone please explain how this option enable_sdch can be disabled when we run Chrome on Windows OS since we dont use command line options on this OS?

Comment 30 by jar@chromium.org, Apr 24 2011

vasan...@ Can you clarify what OS you're using?  On (MS) Windows OS you can indeed use the enable_sdch command line to select a domain like "nonexistantdomain.foo" which will disable it for all "other" domains.  

Comment 31 by Deleted ...@, Jul 10 2011

This issue (very reluctantly) prevented me from using chrome for a long time; thankfully this thread pointed me in the direction of privoxy as the culprit. I'm on Ubuntu 10.04 using privoxy 3.0.15-3.

Rather than modifying privoxy config files (which I hate doing because the syntax is non-obvious to me), a quicker solution is to include google.com (or whatever site(s) is giving you this problem) in the "ignored hosts" field in chrome: Preferences-->Under the hood-->Change proxy settings-->Ignore hosts. Type the name of the site you want privoxy to ignore, click the "add" button and you're good to go.

The only site I've had problems with is google.com, so I'm not worried about privoxy being bypassed for that site, however if your problems occur on sites with lots of ads you want removed, modifying the privoxy config file is likely the only way to go until privoxy fixes the bug.

Incidentally, I checked the privoxy sourceforge site and didn't see any bug reports about this - has anyone posted a bug report that I'm overlooking?
Project Member

Comment 32 by bugdroid1@chromium.org, Oct 12 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

Sign in to add a comment