I tried pushing to a repository at Google Code for the first time today, and I encountered some weird behavior with respect to asking for credentials. If I use the url "https://code.google.com/r/repo/";, everything works; I get prompted for my username/password. But if I instead use the url "https://myuser@xxxxxxxxxxxxxxx/r/repo/";, it doesn't work. I get: $ git push fatal: remote error: Invalid username/password. You may need to use your generated googlecode.com password; see https://code.google.com/hosting/settings without any prompt at all. I bisected it to 986bbc0 (http: don't always prompt for password, 2011-11-04), but I think that is a red herring. It worked before that commit because we always asked for the password, before we even talked to the server. After that commit, we should be reacting to an HTTP 401. But it seems that Google Code's 401 behavior is odd. When t5540 checks this, the conversation goes something like: 1. We do a GET with no "Authorization" header. 2. The server returns a 401, asking for credentials. 3. Curl repeats the GET request, putting the username into the Authorization header. 4. The server returns a 401, again, as our credential is not sufficient. 5. Curl returns the 401 to git; git prompts for the credential, feeds it to curl, and then repeats the request. It works. But with Google Code, the first three steps are identical. But then for step 4, the server returns this: < HTTP/1.1 200 OK < Content-Type: application/x-git-receive-pack-advertisement < X-Content-Type-Options: nosniff < Date: Fri, 15 Mar 2013 11:43:14 GMT < Server: git_frontend < Content-Length: 175 < X-XSS-Protection: 1; mode=block < * Connection #0 to host code.google.com left intact packet: git< # service=git-receive-pack packet: git< 0000 packet: git< ERR Invalid username/password [...] That seems kind of crazy to me. It's generating an HTTP 200 just to tell us the credentials are wrong. Which kind of makes sense; it's the only way to convince the git client to show a custom message when it aborts (rather than producing its own client-side "authorization failed" message). But it takes the retry decision out of the client's hands. And in this case, it is wrong; the failed credential is a result of curl trying the username only, and git never even gets a chance to provide the real credential. Technically this did work before 986bbc0, so it could be considered a regression in git, but I really think that Google Code is in the wrong here. It should either: 1. Always return a 401 for bad credentials. This means it would lose the custom message. But I think that is a good indication that the client should be putting more effort into showing the body of the 401. Probably not all the time, as we do not want to spew HTML at the user, but we could perhaps relay error bodies if the content-type is "application/x-git-error" or something. The downside is that even if we make such a client change and the the Google Code server change sit's behavior, people on older git clients will lose the benefit of the message. 2. Treat a credential with a non-empty username and an empty password specially, and return a 401. This covers the specific case of https://user@host/, but continues to show the custom message when the user provides a wrong password. It does mean that the custom message will not be shown if the user actually enters a blank password at the prompt (but it will still be shown if they get prompted for both username and password and leave both blank). So it's a little hacky, but I think it would work OK in practice. What do you think? -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html