Is Google Burying Firefox With User Agent Strings?
thepowerbase.com
thepowerbase.com
Perhaps it's just a problem with the particular machines he's connecting to? I use Firefox almost exclusively and I haven't seen any resets for ages now.
This explains the Adsense warning because the server-side part of the framework used (gwt) is seeing a different user agent than what the client part is seeing.
Granted, UA sniffing is bad practice on either client or server side, but if you do it and send content tailored for browser A and then see that, strangely, the client is actually browser B, then you are probably allowed to be confused and complain (better than failing in strange ways).
Also knowing that, it's unlikely that something on the server side is causing these connection reset issues because, as I just said: the server still sees a chrome user agent and producing a connection reset error (RST packet) requires connection level involvement (server or somewhere in between, but never the client browser, minus bugs).
In general: be very careful what error messages you see: the Adsense error is different from the gmail error which in turn is (likely) different from the connection reset issue.
Overall there is too much conflicting information to attribute malice or even just intent to Google here.
If I were in that users position, I'd check my firewall and/or proxy configuration (and try disabling HTTP pipelining if it's active in Firefox - it's disabled by default for a reason) as the problem is much more likely somewhere over there.
For example, the javascript file served to a French user using Firefox will contain only French labels, and won't contain any code to deal with IE, Chrome...
User agent sniffing is not always good practice, but, in this case, it results in a nice performance improvement :) You can even use it to have a "production" and a "debug" version of your app. By adding "?debug=true" to your URL, GWT would load the "debug" version, which could for example contain code to log information.
https://developers.google.com/web-toolkit/doc/latest/FAQ_Deb...
Besides, this just doesn't make sense. If this was an attempt to make Firefox look bad then it's a dreadful one. This just serves to make Google services look faulty as Firefox will still work for everything else. Because of this I doubt there is any malice behind this and it is just a bug.
Perhaps this is more to do with a Linux string being picked up vs the Firefox aspect?
Ubuntu Firefox is Mozilla's Firefox coupled with arbitrary modifications by the Ubuntu developers. In principle I respect Ubuntu's position and desire to make things right by their users.
But in practice, having been in the same relationship as an author of Chrome for Linux I can tell you that it's always dangerous to have people who aren't browser developers make modifications to a browser. More than once the Ubuntu Chromium packager made changes to Chrome that were harmful for users because they didn't understand the consequences of their changes.
408 chromium/chromium-20.0.1123.4.ebuild
349 firefox/firefox-12.0.ebuild
42 rekonq/rekonq-0.9.2.ebuild
98 midori/midori-0.4.5.ebuild
90 epiphany/epiphany-3.4.1.ebuild
61 conkeror/conkeror-1.0_pre20120223.ebuild
64 dillo/dillo-3.0.2.ebuildFor some years, lots of vendors had patches to mess around with perl's default @INC order, all of which were distro-specific and not really generalisable, because nobody had bothered to submit the upstream change that would have got rid of that whole class of patches.
Now, I suspect the reasons for that may have been to do with perl's then rather slower pace of releases, so people didn't see the point when perl5 version 10 was apparently not getting any closer, but just because that reason doesn't apply to chromium doesn't mean there isn't a similarly convincing one for local patches.
It also doesn't mean there -is-; I've always been fond of local patches to software being corresponded with a distro bug and preferably with an upstream bug explaining the rationale; it may not avoid the necessity for the patch but it at least means the conversation that led to it is both visible and involved the right people.
Perhaps changing the User-Agent is making a difference, but not in the way he expects. For example, his 'Firefox' User-Agent is 77 characters long, while his 'Chrome' User-Agent is 106. That might be the difference between some packets more often being a size that triggers a problem somewhere on the path. (Or, the string or size might be triggering different handling in some transparent proxy.)
I believe that code might go something more like
> if (!SPDY-capable) redirect_to_regular_somewhat_overloaded_http_load_balancers_without_resetting_client_ttl_value();
http://www.zdnet.com/blog/btl/google-paying-mozilla-300-mill...
They pay that money not as a charitable donation but because the deal makes them more in advertising than it costs. From a monetary point of view, of course it would be better for them if all that advertising came from Chrome, so they still make the money but they don't have to pay $300m because they already own the browser.
However, I got loads of "Connection was reset" when trying to use the powerbase site where this article was. Server seems very very slow or something is wrong with it.
Off topic: the pagination with blogs/news sites articles is total nonsense...
Furthering the derail: Increases ad-space. Makes perfect simple sense to me, though I may not agree with it all the time (or ever).
You should use UA sniffing to fix this bug.
if (document.querySelector('.title a').innerHTML.match(/^Is .*\?$/)) { console.log('Probably not.') }
(HN's markup is terrible, it doesn't use headers)
(OK, that's the cranky developer-speak for "If you can reproduce the problem while taking a packet capture I'd be glad to help troubleshoot".)
I don't work at Google or on Chromium but I can take a look at it and pass it along if it looks like something out of the ordinary. My email is in my profile.
I also have a mobile broadband dongle (UK - T Mobile) which does weird and unpleasant things to the connection. (All images are proxied with poor quality versions, javascript is inserted into the page asking for key combos to improve image quality; all alt tags are re-worded, etc.)
I blame any sub-optimality on the shitty broadband from T Mobile and the weird proxies; then on overload from HN, then on errors I've made.
Works fine for me, Chrome & FF on Windows.
What does that mean? Well, depending on your region, ISP, and a bit of luck, you'll hit different Google servers, at different places, etc.
Some of them have different things, some of them have new updates others don't, etc.
Which may be an explanation for the author having issues (then again it's just ONE possibility).
Specially it could be that regular HTTP was failing and not SPDY for example.
Personally I haven't had that either.
However, Firefox nightly builds on Windows work without a hitch. I am suspecting some firefox+linux combination messing things up. My two cents.
Try in windows, might give more leads...
You shouldn't care which browser it is, you should care what features it supports (or doesn't).
It's not all the time and I haven't investigated to find out what the problem is... Bing search always works so I just use that.
Wow, break out the tinfoil hats.