{"thread":{"id":"33295","subject":"More detailed error message for 403 forbidden.","startedAt":"2013-03-27T03:29:57Z","lastAt":"2013-03-31T09:17:50Z","messageCount":7,"participants":["Yi, EungJun","Jeff King","Jonathan Nieder","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"212362","messageId":"CAFT+Tg_PwAS__AYCwQQZjy4LVvAMZFJuJ+ediDJpRnxx73qMMg@mail.gmail.com","threadId":"33295","inReplyTo":null,"subject":"More detailed error message for 403 forbidden.","fromName":"Yi, EungJun","fromEmail":"semtlenori@gmail.com","sentAt":"2013-03-27T03:29:57Z","receivedAt":"2013-03-27T03:29:57Z","isPatch":false,"sender":{"key":"semtlenori@gmail.com","avatar":"https://gravatar.com/avatar/8363435d2badb3450df0dd7c4ec2113f6e1d62c44dd3cf7dfe83c5a389b8a9bf?d=mp&s=160"},"body":"Currently, if user tried to access a git repository via HTTP and it\nfails because the user's permission is not enough to access the\nrepository, git client tells that http request failed and the error\nwas 403 forbidden.\n\nBut It is not enough for user to understand why it fails, especially\nif the user don't know the username because git-credential-osxkeychain\nauthenticate implicitly without user knowing.\n\nIt would be much better if git client shows response body which might\ninclude an explanation of the failure. For example,\n\nbefore:\n\n$ git clone http://localhost/foo/bar\nerror: The requested URL returned error: 403 while accessing\nhttp://localhost/foo/bar\nfatal: HTTP request failed\n\nafter:\n\n$ git clone http://localhost/foo/bar\nerror: The requested URL returned error: 403 while accessing\nhttp://localhost/foo/bar\nremote: User 'me' does not have enough permission to access the repository.\nfatal: HTTP request failed\n"},{"id":"212559","messageId":"20130328183601.GA11914@sigill.intra.peff.net","threadId":"33295","inReplyTo":"CAFT+Tg_PwAS__AYCwQQZjy4LVvAMZFJuJ+ediDJpRnxx73qMMg@mail.gmail.com","subject":"Re: More detailed error message for 403 forbidden.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-28T18:36:01Z","receivedAt":"2013-03-28T18:36:01Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 27, 2013 at 12:29:57PM +0900, Yi, EungJun wrote:\n\n> Currently, if user tried to access a git repository via HTTP and it\n> fails because the user's permission is not enough to access the\n> repository, git client tells that http request failed and the error\n> was 403 forbidden.\n\nThe situations in which you'll get a 403 depend on how the server is\nconfigured. For instance, on github.com, if you successfully\nauthenticate but are not authorized to access a repository, you get a\n404 (we do this to avoid leaking information about which private\nrepositories exist). But we do provide a 403 if you try to access the\nrepository with a non-smart-http client.\n\nSo the \"403 forbidden\" there is not about your account, but about the\nmethod; if git is going to give a more verbose message, it needs to be\ncareful not to mislead the user.\n\n> It would be much better if git client shows response body which might\n> include an explanation of the failure. For example,\n> [...]\n> $ git clone http://localhost/foo/bar\n> error: The requested URL returned error: 403 while accessing\n> http://localhost/foo/bar\n> remote: User 'me' does not have enough permission to access the repository.\n> fatal: HTTP request failed\n\nI agree that is the best way forward, as that means the server is\ntelling us what is going on, and we are not guessing about the meaning\nof the 403.\n\nOne problem is that the content body sent along with the error is not\nnecessarily appropriate for showing to the user (e.g., if it is HTML, it\nis probably not a good idea to show it on the terminal). So I think we\nwould want to only show it when the server has indicated via the\ncontent-type that the message is meant to be shown to the user. I'm\nthinking the server would generate something like:\n\n   HTTP/1.1 403 Forbidden\n   Content-type: application/x-git-error-message\n\n   User 'me' does not have enough permission to access the repository.\n\nwhich would produce the example you showed above.\n\n-Peff\n"},{"id":"212560","messageId":"20130328184120.GQ28148@google.com","threadId":"33295","inReplyTo":"20130328183601.GA11914@sigill.intra.peff.net","subject":"Re: More detailed error message for 403 forbidden.","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-03-28T18:41:20Z","receivedAt":"2013-03-28T18:41:20Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jeff King wrote:\n\n> One problem is that the content body sent along with the error is not\n> necessarily appropriate for showing to the user (e.g., if it is HTML, it\n> is probably not a good idea to show it on the terminal). So I think we\n> would want to only show it when the server has indicated via the\n> content-type that the message is meant to be shown to the user. I'm\n> thinking the server would generate something like:\n>\n>    HTTP/1.1 403 Forbidden\n>    Content-type: application/x-git-error-message\n>\n>    User 'me' does not have enough permission to access the repository.\n>\n> which would produce the example you showed above.\n\nWould it make sense to use text/plain this way?\n\nCurious,\nJonathan\n"},{"id":"212561","messageId":"20130328184530.GA14691@sigill.intra.peff.net","threadId":"33295","inReplyTo":"20130328184120.GQ28148@google.com","subject":"Re: More detailed error message for 403 forbidden.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-28T18:45:30Z","receivedAt":"2013-03-28T18:45:30Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 28, 2013 at 11:41:20AM -0700, Jonathan Nieder wrote:\n\n> Jeff King wrote:\n> \n> > One problem is that the content body sent along with the error is not\n> > necessarily appropriate for showing to the user (e.g., if it is HTML, it\n> > is probably not a good idea to show it on the terminal). So I think we\n> > would want to only show it when the server has indicated via the\n> > content-type that the message is meant to be shown to the user. I'm\n> > thinking the server would generate something like:\n> >\n> >    HTTP/1.1 403 Forbidden\n> >    Content-type: application/x-git-error-message\n> >\n> >    User 'me' does not have enough permission to access the repository.\n> >\n> > which would produce the example you showed above.\n> \n> Would it make sense to use text/plain this way?\n\nMaybe. But I would worry somewhat about sites which provide a useless\nand verbose text/plain message. Ideally an x-git-error-message would be\nno more than few lines, suitable for the error message of a terminal\nprogram. I would not want a site-branded \"Your page cannot be found.\nHere's a complete navigation bar\" page to be spewed to the terminal.\nThose tend to be text/html, though, so we may be safe. It's just that\nwe're gambling on what random servers do, and if we show useless spew\neven some of the time, that would be a regression.\n\n-Peff\n"},{"id":"212569","messageId":"7vk3ortk3o.fsf@alter.siamese.dyndns.org","threadId":"33295","inReplyTo":"20130328183601.GA11914@sigill.intra.peff.net","subject":"Re: More detailed error message for 403 forbidden.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-28T19:11:55Z","receivedAt":"2013-03-28T19:11:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> One problem is that the content body sent along with the error is not\n> necessarily appropriate for showing to the user (e.g., if it is HTML, it\n> is probably not a good idea to show it on the terminal). So I think we\n> would want to only show it when the server has indicated via the\n> content-type that the message is meant to be shown to the user. I'm\n> thinking the server would generate something like:\n>\n>    HTTP/1.1 403 Forbidden\n>    Content-type: application/x-git-error-message\n>\n>    User 'me' does not have enough permission to access the repository.\n>\n> which would produce the example you showed above.\n\nActually, isn't the human-readable part of the server response meant\nfor this kind of thing?  I.e.\n\n\tHTTP/1.1 403 User 'me' not allowed to accept the repository.\n"},{"id":"212576","messageId":"20130328201826.GA24103@sigill.intra.peff.net","threadId":"33295","inReplyTo":"7vk3ortk3o.fsf@alter.siamese.dyndns.org","subject":"Re: More detailed error message for 403 forbidden.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-28T20:18:26Z","receivedAt":"2013-03-28T20:18:26Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 28, 2013 at 12:11:55PM -0700, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > One problem is that the content body sent along with the error is not\n> > necessarily appropriate for showing to the user (e.g., if it is HTML, it\n> > is probably not a good idea to show it on the terminal). So I think we\n> > would want to only show it when the server has indicated via the\n> > content-type that the message is meant to be shown to the user. I'm\n> > thinking the server would generate something like:\n> >\n> >    HTTP/1.1 403 Forbidden\n> >    Content-type: application/x-git-error-message\n> >\n> >    User 'me' does not have enough permission to access the repository.\n> >\n> > which would produce the example you showed above.\n> \n> Actually, isn't the human-readable part of the server response meant\n> for this kind of thing?  I.e.\n> \n> \tHTTP/1.1 403 User 'me' not allowed to accept the repository.\n\nIn theory, yes. But I don't think that most servers make it very easy to\nuse custom \"reason phrases\" (that is the rfc 2616 term for them). At\nleast I could not easily figure out how to make Apache do so. You can do\nso from CGIs, but I think you'd want to customize some of this at the\nHTTP server level (e.g., overriding 404s with a custom message). There's\nmuch better support at that level for custom error documents (e.g.,\nApache's ErrorDocument).\n\nI do not configure http servers very often, though, so I could be wrong\nabout what is normal practice, and what is easy to do.\n\n-Peff\n"},{"id":"212722","messageId":"CAFT+Tg-fvp-3s70y5UQH86pp_nu=HRNFye_kbRa7VJSQuv=iLg@mail.gmail.com","threadId":"33295","inReplyTo":"20130328184530.GA14691@sigill.intra.peff.net","subject":"Re: More detailed error message for 403 forbidden.","fromName":"Yi, EungJun","fromEmail":"semtlenori@gmail.com","sentAt":"2013-03-31T09:17:50Z","receivedAt":"2013-03-31T09:17:50Z","isPatch":false,"sender":{"key":"semtlenori@gmail.com","avatar":"https://gravatar.com/avatar/8363435d2badb3450df0dd7c4ec2113f6e1d62c44dd3cf7dfe83c5a389b8a9bf?d=mp&s=160"},"body":">\n> Maybe. But I would worry somewhat about sites which provide a useless\n> and verbose text/plain message. Ideally an x-git-error-message would be\n> no more than few lines, suitable for the error message of a terminal\n> program. I would not want a site-branded \"Your page cannot be found.\n> Here's a complete navigation bar\" page to be spewed to the terminal.\n> Those tend to be text/html, though, so we may be safe. It's just that\n> we're gambling on what random servers do, and if we show useless spew\n> even some of the time, that would be a regression.\n>\n> -Peff\n\nI completely agree with you.\n\nAnd should git client need to add x-git-error-message in Accept header\nand/or perhaps language preference in Accept-Language header?\n\n    Accept: x-git-error-message, */*;q=0.8\n    Accept-Language: ko,en;q=0.8\n"}]}