Google+ supposedly has a built-in chat feature (like GMail). In Ephy all I get is a "Too many redirect errors". Checking the Inspector the page apparently tries to do a GET of some insanely complex talkgadget.google.com URI (can't copy&paste though? another bug? :)).
I saw this on Google Calendar some time ago as well. Gustavo recently fixed an issue where Google Calendar was detecting WebKitGTK+ as mobile. I wonder if that's happening here as well.
I get the same error when I try to reach http://www.sjscycles.co.uk/ in Epiphany. Is this the same problem or should I file a new bug?
This nasty issue is still present in libwebkit 1.8. As Chromium is working this could be part of the gtk framwork?
(In reply to comment #2) > I get the same error when I try to reach http://www.sjscycles.co.uk/ in Epiphany. Is this the same problem or should I file a new bug? I confirmed that this fails in Epiphany and works great in GtkLauncher, so I suspect that this is a user-agent problem.
(In reply to comment #4) > I confirmed that this fails in Epiphany and works great in GtkLauncher, so I suspect that this is a user-agent problem. We already pretend (in theory) to be Google Chrome, what else should be do here?
(In reply to comment #5) > (In reply to comment #4) > > I confirmed that this fails in Epiphany and works great in GtkLauncher, so I suspect that this is a user-agent problem. > > We already pretend (in theory) to be Google Chrome, what else should be do here? Actually it's not an UA issue. It's easy to test with curl or wget that the UA reported by ephy is perfectly fine. The problem (at least for me in the www.sjscycles.co.uk site) is that we're sending a Cookie with invalid characters for the IIS server. I'll take a look.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > I confirmed that this fails in Epiphany and works great in GtkLauncher, so I suspect that this is a user-agent problem. > > > > We already pretend (in theory) to be Google Chrome, what else should be do here? > > Actually it's not an UA issue. It's easy to test with curl or wget that the UA reported by ephy is perfectly fine. The problem (at least for me in the www.sjscycles.co.uk site) is that we're sending a Cookie with invalid characters for the IIS server. I'll take a look. So yeah, it turned out that I have some .co.uk cookies in the ephy cookie jar that were confusing the server. After I removed them everything worked fine. So here the real bug is IMO that we are storing "supercookies" http://en.wikipedia.org/wiki/HTTP_cookie#Supercookie.
This bug is now handled in libsoup: https://bugzilla.gnome.org/show_bug.cgi?id=673802
The bug is still there. I'll take a look at it again.
OK, so after examining carefully the HTTP communications I can conclude that the problem here are cookies. Basically Google+ tries to set some cookies with domain talkgadget.google.com from a plus.google.com domain, which we basically reject because they don't pass the domain match test. Thing is that Chrome or FF accept them without any problem...
(In reply to comment #10) > OK, so after examining carefully the HTTP communications I can conclude that the problem here are cookies. Basically Google+ tries to set some cookies with domain talkgadget.google.com from a plus.google.com domain, which we basically reject because they don't pass the domain match test. > > Thing is that Chrome or FF accept them without any problem... I think I know the reason, and the problem is that we don't properly handle the case of multiple redirects, as the firstPartyForCookies is not updated properly.
OK, I have a one-liner fix for this issue. Apparently tests are still working fine, but before posting it here I need to double-check if there is any test covering this case.
Created attachment 167139 [details] Forward cookies on redirects So that's what I'm talking about. Basically that page requires some cookies to be forwarded for a proper authentication. Honestly I am not sure about if doing something like this is either standard complaint and/or secure. Dan any comment? PS: not setting the r? because I this needs a tests, a proper ChangeLog, blah blah
There's no standard for "first party cookies", but this change definitely seems right to me
Created attachment 189119 [details] Patch
Comment on attachment 189119 [details] Patch Is it possible to get a test for this?
Created attachment 190057 [details] Patch
Comment on attachment 190057 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=190057&action=review Nice. Just a couple small things before landing. > LayoutTests/http/tests/cookies/resources/redirect.php:6 > + if ($_GET['step'] == 1) > + { > + header("HTTP/1.0 302 Found"); > + header('Location: http://localhost:8000/cookies/resources/redirect.php?step=2'); > + } Do you mind converting this file to use WebKit style when landing? I also recommend giving it a slightly more descriptive name. Since it isn't shared, maybe you can just name it after the test? > LayoutTests/http/tests/cookies/resources/redirect.php:18 > + echo "<p>PASSED: Cookie successfully set</p>\n"; I'm not sure the paragraph tag is necessary here. > LayoutTests/http/tests/cookies/resources/redirect.php:22 > + echo "<p>FAILED: Cookie not set</p>\n"; Ditto.
Committed r143931: <http://trac.webkit.org/changeset/143931>
This regression test breaks other cookie tests, filed bug 110844.
I think this is still causing some flakiness on Mac. http/tests/cookies/third-party-cookie-relaxing.html http/tests/plugins/third-party-cookie-accept-policy.html I filed https://bugs.webkit.org/show_bug.cgi?id=111650