Re: protocol: add Accept-Language header if possible

[Junio C Hamano <gitster@pobox.com>]

"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.

But since you added an explicit CC, let me try.  Do not expect any
high quality answers, though.

>>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.