Re: Re: protocol: add Accept-Language header if possible

["lilinchao@oschina.cn" <lilinchao@oschina.cn>]

>"lilinchao@oschina.cn" <lilinchao@oschina.cn> 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@navercorp.com> 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.