>"lilinchao@xxxxxxxxxx" <lilinchao@xxxxxxxxxx> writes: > >I am not your personal help-desk. Please don't Cc: questions to me >unless it is a piece of code I wrote and am familiar with. First of all, sorry to disturb you, I thought you're the person most familiar with those codes :) This is not just a question, as I am planing to do some work on git to let server side know the client end locale info for every HTTP request, this is very helpful for many non-English speakers to understand what happened when git throw some error messages. But first I want to know if it is worth doing, and I'm curious to know the original design purpose, especially when I see inconsistent behavior, so I came here for help. >But since you added an explicit CC, let me try. Do not expect any >high quality answers, though. > Thanks a lot PS: I've tried to Cc Yi EungJun <eungjun.yi@xxxxxxxxxxxxx> but my email was returned, because "The receiving address does not exist, or the receiving address is disabled.". So I don't know who I should Cc to now. >>>Git server end's ability to accept Accept-Language header was >>>introduced in f18604bbf2(http: add Accept-Language header if >>>possible) but it seems that only refs discovering stage has this >>>ability: > >I do not think we do anything special on the server end. The said >commit taught client side to learn end-user's locale and throw >accept-language header at the other side. > >I am not sure how much it helps in the smart HTTP, especially in >later phases of the transfer, in the first place. Back in dumb HTTP >walker days, a failure to fetch single object would have resulted in >an error message generated by the webserver directly shown at the >client end, but is that still true even if we use the smart HTTP to >encapsulate the git native protocol exchange? > >I highly suspect that any calls to get_accept_language() helper, or >failure to call it, in the smart HTTP codepath is not something >designed but just happened by accident. If it helps to issue the >header to various requests, I think it would be good for >consistency. Anything that uses http.c::http_request() should get >the header for free, so depending on the reason why some requests do >not use it, adding it might involve some refactoring, though. I think every HTTP request from git client should send this header to server end, to tell the server which language it prefers, this would be very friendly for user end.
