Iron (Chrome/Chromium) has problems with Sidki filters

[Mele20]

I installed Iron browser a few days ago. I wouldn't touch Chrome/Chromium because of the privacy issues but Iron strips out all that.

I like the browser but it is not recognizing IE's setting for "use HTTP1.1 through proxy connections". I noticed the problem immediately as page compression was turned off on my home site of dslreports.com. Then I saw the second symptom of that IE setting not being used when I went to reply to a forum thread. I did not get the entire thread as scrollable above the reply box but just got the text of the specific post I was replying to.

Tonight, I installed Iron on a virtual machine running XP Pro like my host computer is doing, but the virtual machine has IE8, whereas, my host machine has IE6 still (I rarely use IE). I wanted to see if Iron would work better if IE8 was installed since Iron uses IE settings and IE8 ones would be newer. But I had the same problems as far using Proxo with Iron.

So, I switched to Scott's ancient filters (default in the list ...not sure which level) and those work fine. I have page compression on at dslreports and I get the full thread above a forum reply box. So, that says to me that something in Sidki's latest official (not the new alpha) filters disagrees with Iron/Chrome/Chromium. I have Sidki filters back to 2005 and I have this problem with those also.

Since I spend a great deal of time at dslreports.com, I want things working properly there. Anyone else here using Iron/Chrome/Chromium who has these problems? My default browser is Opera 10.61 but I would like to also use Iron some of the time if this problem can be fixed. It has two features that I really miss in Opera.

[JJoe]

I have another knock-off of Chrome, ChromePlus.

ChromePlus, Iron, and Chrome send a UserAgent header to DSLReports that looks like

Quote:Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.9 Safari/533.2 ChromePlus/1.3.9.0

Sidki's sets change this User-Agent to

Quote:Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/533.99

or

Quote:Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US)

The modified UserAgent causes the loss of page compression, for me.
ChromePlus is using HTTP 1.1 through the Proxomitron.

Adding

Code:

www.dslreports.com/     $SET(0=i_ua:0.)
i.dslr.net/             $SET(0=i_ua:0.)

to the user list (Exceptions-U or IncludeExclude-U) enabled page compression.

Quote:I did not get the entire thread as scrollable above the reply box but just got the text of the specific post I was replying to.

Appears to have also fixed this for 2009-02-13 (UPDATE 06-06). Didn't see "entire thread as scrollable" problem while testing alpha.

HTH

[Graycode]

JJoe seems to have your answer.

Also beware those browsers using Google's SDCH encoding method.
http://prxbx.com/forums/showthread.php?tid=1379
http://blog.endpoint.com/2009/07/sdch-sh...-over.html

The browsers will send a header such as:
Accept-Encoding: gzip,deflate,bzip2,sdch

When any content is modified (by Proxo), a subsequent page request encoded with SDCH will only send the portions the Server thinks is the updated difference. That may result in garbage since data offsets will be wrong.

[sidki3003]

Re issue with release config: what JJoe says.

The difference between release config:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US)
...and alpha config:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/533.99
...is that i came across a couple of sites lately, testing for "AppleWebKit". Writing back this string also enables the multi-post iframe in DSLR replies.

Now, DSLR's compression check is testing for "gecko", which happens to be present in: (KHTML, like Gecko)

So, for the alpha i prefer a generic approach, i.e. replacing the existing Mozilla block in User-Agents.ptxt with:

Code:

## If Firefox, SeaMonkey, Chrome, Safari:
## ----------------------------------------------------------------------------
Mozilla/5.0(^$TST(keyword=*.f_ua_(^[a-z]++moz)*))(*(; rv:*Gecko/[#*:*]
  ( Firefox/[#*:*].[#*:*]$SET(3=.9.9)|)|\)
  (*\s(Gecko/[#*:*]|AppleWebKit/(*.)+{1}$SET(3=99))|))\2
  [0-9.]+( $NEST(\(,*gecko*,\))|)\4|$SET(2=\)))
  $SET(1=Mozilla/5.0 \(Windows; U; Windows NT 6.1; en-US\2\3\4)

Let me know if you suspect these conclusions being incorrect.


Graycode: Very interesting observation!
The configs aren't affected, however. In the outbound accept-encoding header everything but gzip & deflate is discarded.

edit (Sep 10): list expression updated

[Graycode]

Here's an interesting blog about the upcoming IE9's use of a short User-Agent string:
http://zoompf.com/blog/2010/03/the-big-p...king-about

I always thought it odd that a server would look at both the Accept-Encoding and the User-Agent headers to determine whether to reply with compression.

Quote:Unfortunately there are some bugs in certain older web browsers where these browsers would send an Accept-Encoding header telling the web server they supported HTTP compression when they really didn’t. The biggest culprit was IE6 before SP1. This browser had a bug would it would internally cache the compressed version of a CSS or JavaScript response and would try (and fail) to directly process the compress bytes. There are also certain versions of Netscape 4.x that did not properly handle HTTP compression despite using Accept-Encoding to instruct the server that it did.

Too bad some servers look for User-Agent strings they know to be good vs. only using exceptions to identify those that are faulty.

It's nice that Microsoft won't be disclosing as much crap in their UA any longer. Personally though I still don't think a web server needs to know my real computer architecture or the OS that browser's running in.

[ProxRocks]

very interesting indeed...

kinda funny how the article links to a list of over 480 IE8 user-agent strings and mine isn't listed... just more proof to the overwhelming number of IE8 UA's, lol...

[sidki3003]

Yeep, nice roundup.

(Sep. 08, 2010 04:18 PM)Graycode Wrote:  It's nice that Microsoft won't be disclosing as much crap in their UA any longer. Personally though I still don't think a web server needs to know my real computer architecture or the OS that browser's running in.

Which reminds me... I guess i should adjust the user-agent platform value for Windows 7, i.e. NT 6.1, as it is probably becoming the most used OS sometime soon...

[sidki3003]

Post #4: The updated entry for User-Agents.ptxt had a bug, sorry.
Corrected.

[Mele20]

(Sep. 04, 2010 03:46 PM)JJoe Wrote:  I have another knock-off of Chrome, ChromePlus.

Sidki's sets change this User-Agent to

Quote:Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/533.99

or

Quote:Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US)

The modified UserAgent causes the loss of page compression, for me.
ChromePlus is using HTTP 1.1 through the Proxomitron.

Adding

Code:

www.dslreports.com/     $SET(0=i_ua:0.)
i.dslr.net/             $SET(0=i_ua:0.)

to the user list (Exceptions-U or IncludeExclude-U) enabled page compression.

Exactly where in the IncludeExclude-U list do I add it? I added it at the bottom and Iron is still identifying as Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) i shouldn't need to reboot should I? I closed Iron and reopened it after I added the code.

Iron just issued an update a couple of days ago for the version so I now have 6.0.475.

It turns out to not matter much because Iron STILL has no way to change the colors for visited and unvisited links. It uses IE default choices and I cannot stand the horrible blue that IE default uses for UNvisited links. It is a garish blue and very difficult to read. I have IE6 on XP Pro set to use a darkish green for unvisited links and I have Opera, Firefox, etc set to use the same color. But for some reason Iron is using IE's default color not the one I have chosen. Iron is using MY choice of color for visited links but those are a lot less number of links so it is the UNvisited color that I really need Iron to use my IE choice for.

I don't understand why Iron would not offer a way to choose what colors you want for the links. Really stupid. Even this latest version doesn't offer a way. Is Chrome itself like that??? If so, UGH. I posted in the Iron forum and it is very difficult to post there because even the English version of the forum has most of the forum in German. I posted about ten days ago with this question and got no replies. So, I won't be using Iron at any forums and I mostly visit forums when surfing.

What is worse, even with this new version 6 of Iron, I have only NINE tabs open yet it is using OVER 300,000 K RAM!!! I have 55 tabs open on Opera 10.61 currently and it is using only 100,000 K RAM (will climb when it is actively used but it won't go much above 200,000 K RAM and that is with 55 tabs ...minimized now and I am typing this on Iron). Iron never releases the RAM either when minimized. Iron is fast but no faster than Opera 10.61 and Iron has almost no configurability while Opera has so much configurability that you could spend all your time just playing with all the ways to configure it.

[ProxRocks]

Chrome, Chromium, and Iron - all of them, STUPIDLY, don't provide their own link coloring... Not sure about this ChromePlus...

i've always felt the LACK of configurability places these browsers in the "designed for third graders" (or perhaps "designed for grandparents", take your pick) classification...

[Mele20]

Thanks ProxRocks for letting me know that stupidity about link coloring is in all Chrome/chrome knockoffs. I also don't understand why Chrome/Iron uses IE settings! I thought Google and Microsoft were enemies...so Google asks Microsoft to allow Chrome to not be bothered with having its OWN options but to use those of IE's and Microsoft says "Hunky-dory, by darn that is a great idea and I'll be tickled pink to help my rival in this way." Doesn't make sense to me.

I just had another thought. I was trying to update Opera just now (it failed) and that made me think is Sidki's filters the culprit that makes EVERY browser after updating insist that you have an OLD version? Opera and Fx, after updating take you to an Opera or Fx page that is supposed to welcome you to the latest version of those browsers. But, instead, I always get a page that claims I have an ANCIENT version of Fx or Opera and tells me I desperately need to upgrade. I just upgraded and the upgrade was successful. So, is it the browser string that Proxo is using that makes Fx and Opera believe that I did not upgrade but am instead using an ancient version? I've been trying to figure this out for ages...don't know why it didn't occur to me before that the culprit is probably Proxo. I don't mind as long I know why I keep getting the warning page in Fx and Opera after updating.

Edit: Ok, I just tried again and this time Opera updated properly to 10.62, build 3500 but I got that welcome page again about having an old version.

[ProxRocks]

whenever i do an "upgrade", i set my firewall to block ALL traffic, then to the upgrade/install, then run the newly installed and DO NOT let it access the 'net on "first run" (so i get a "cannot connect" on first run, so what), i then go and set all of the "settings", close it, then return my firewall to start allowing "custom" traffic to pass...

when i run the software and go to "help -> about", it shows the upgraded version number, that's good enough for me, those "first run" 'welcome' pages are "retarded"...

[JJoe]

Quote:Exactly where in the IncludeExclude-U list do I add it? I added it at the bottom and Iron is still identifying as Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US)

I put it at the bottom. Make sure you add it to the correct file. SIDKI 2009-02-13 (UPDATE 06-06) uses IncludeExclude-U. SIDKI 2009-05-24 ALPHA 4 uses Exceptions-U.

You may be able to see the current user list's entries at IncludeExclude-U (or Exceptions-U) on http://local.ptron/.pinfo/lists/ . Click on user list's link in the "Name" column.

Do you have more than one line in IncludeExclude-U (or Exceptions-U) that matches www.dslreports.com/ or i.dslr.net/. Sidki's sets use the first matching line. You may need to combine lines.

Quote: i shouldn't need to reboot should I?

I don't think so but your computer's environment is more complicated than mine.

Quote:So, is it the browser string that Proxo is using that makes Fx and Opera believe that I did not upgrade but am instead using an ancient version?

Could be, I have seen warnings from websites due to the useragent header. I don't remember a warning for Opera or Firefox but I haven't upgraded for months and I always download the installer. Also, when installing/updating programs, I may disable or bypass the Proxomitron.

HTH


Edit: added reference to i.dslr.net/, broke link to www.dslreports.com/

[whenever]

(Sep. 14, 2010 12:17 PM)Mele20 Wrote:  So, is it the browser string that Proxo is using that makes Fx and Opera believe that I did not upgrade but am instead using an ancient version?

I think so.

The below entry in User-Agents.ptxt

Code:

## If Opera:
## ----------------------------------------------------------------------------
Opera/(^$TST(keyword=*.f_ua_(^[a-z]++op)*))(\w)\2
  $SET(1=Opera/\2 (Windows NT 5.1; U))

Change the Opera User Agent string from:

Code:

User-Agent: Opera/9.80 (Windows NT 5.1; U; en) Presto/2.6.35 Version/10.70

To:

Code:

User-Agent: Opera/9.80 (Windows NT 5.1; U)

Which strip off the real version number.

[sidki3003]

Just in case you want to have mentioned UA strings adjusted in the next config:

I did google my way to understand the Opera scenario:
Major version string frozen at 9.80 due to inflexible sniffer scripts, etc...

After updating Opera i got the relevant string-testing URL:
http://www.opera.com/portal/upgrade/
It does test the "Version" field, but not the "Presto" one. Any site testing for Presto?

I did not see any similar issue with Firefox. The last update simply brought me to:
http://www.mozilla.com/en-US/firefox/3.6.10/whatsnew/


Generally, everyone who likes to have things fixed/updated/added, please try to do the detective work yourself!