When using a Google Account to login to Gerrit Code Review (review.source.android.com) the OpenID authentication process stops when a 302 redirect is issued by www.google.com and is not executed by WebKit. Observed in both: Safari 3.2.1 (5525.27.1) Chrome 1.0.154.48 Steps to reproduce: - Have a Google Account ready (https://www.google.com/accounts/NewAccount) - Go to http://www.google.com/ - Verify you are signed into the Google Account (check top right). If not, sign in now with "Sign In" link. - Go to https://review.source.android.com/ - Click "Sign In" in top right - Click "Sign in with a Google Account" - DO NOT CHECK "Remember me" - Click "Continue Sign-In" button - IFrame gets stuck. It ignored a 302 redirect sent by www.google.com. This exact procedure works fine in Opera, Firefox, MSIE, and older versions of Safari (3.0). However, a slightly different procedure permits the login to work: - Go to http://www.google.com/ - Verify you are signed out. Click "Sign Out" in top right if necessary. - Go to https://review.source.android.com/ - Click "Sign In" - Click "Sign In" in top right - Click "Sign in with a Google Account" - Enter your Google Account information - Sign In - DO NOT CHECK "Remember me" - Click "Continue Sign-In" button
Turns out to be a combination of factors, all of them unrelated to WebKit. The server in question is Jetty, with a 4096 byte limit on the entire HTTP request. The OpenID authentication process uses a relatively large cookie (about 1.5 KB) and long URLs with lots of data encoded in them. Combined with the standard headers used by the Safari and Chrome user agents, this overflows Jetty's request limit. (Other browsers must be using slightly smaller user agent and accept headers, and thus avoid the overflow.) - Increasing the Jetty request buffer is one possible solution. - Switching the OpenID peers to using POST based requests is another. Neither of which has anything to do with WebKit, or a browser implementing it.