From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D7712C433EF for ; Fri, 3 Jun 2022 19:09:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349091AbiFCTJN (ORCPT ); Fri, 3 Jun 2022 15:09:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40350 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349098AbiFCTJM (ORCPT ); Fri, 3 Jun 2022 15:09:12 -0400 Received: from pb-smtp1.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A3190393C4 for ; Fri, 3 Jun 2022 12:09:10 -0700 (PDT) Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id CEB4A12F159; Fri, 3 Jun 2022 15:09:08 -0400 (EDT) (envelope-from junio@pobox.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=a1uh7gLMzGj6CAvR1WXTBYyMydx5nujABX5xvr /tGOw=; b=RtZcDaxab4TTOeQBQhqxwhzqxi+sbGEftaTY1jf+3WkHoaIuMNxcJ+ Ixkw63QkiavlXdCiGnxa2xzSSncN7AAxW8ALDyNn0HSnA2R/jH4FqEZz7CIda5lD zlIUT5A85qW3pXas/Ih8VrZzAuO0bSzF8Dk8LtIOmcGv6nfX2Q0G4= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id B211412F158; Fri, 3 Jun 2022 15:09:08 -0400 (EDT) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [34.83.92.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 6791412F155; Fri, 3 Jun 2022 15:09:06 -0400 (EDT) (envelope-from junio@pobox.com) From: Junio C Hamano To: lilinchao@oschina.cn Cc: git Subject: Re: protocol: add Accept-Language header if possible References: <2022060211034177301214@oschina.cn> <202206040227197341312@oschina.cn> Date: Fri, 03 Jun 2022 12:09:04 -0700 In-Reply-To: <202206040227197341312@oschina.cn> (lilinchao@oschina.cn's message of "Sat, 4 Jun 2022 02:33:30 +0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: A3BACF30-E370-11EC-8F5A-5E84C8D8090B-77302942!pb-smtp1.pobox.com Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org "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.