From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Maxime Devos Newsgroups: gmane.lisp.guile.devel Subject: RE: Allowing extended HTTP methods Date: Thu, 28 Mar 2024 17:17:49 +0100 Message-ID: <20240328171749.4GHn2C00Y4SDPei06GHosd@albert.telenet-ops.be> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_F6E2AAE8-D773-4091-8ECD-BE6C315C055A_" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19388"; mail-complaints-to="usenet@ciao.gmane.io" To: Ryan Raymond , "guile-devel@gnu.org" Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Thu Mar 28 17:18:21 2024 Return-path: Envelope-to: guile-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rpsSJ-0004kE-QW for guile-devel@m.gmane-mx.org; Thu, 28 Mar 2024 17:18:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rpsS0-0006BD-EW; Thu, 28 Mar 2024 12:18:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rpsRx-0006B2-R9 for guile-devel@gnu.org; Thu, 28 Mar 2024 12:17:58 -0400 Original-Received: from albert.telenet-ops.be ([2a02:1800:110:4::f00:1a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rpsRv-00071x-4B for guile-devel@gnu.org; Thu, 28 Mar 2024 12:17:57 -0400 Original-Received: from [IPv6:2a02:1808:2:f159:c48e:b31f:6650:1863] ([IPv6:2a02:1808:2:f159:c48e:b31f:6650:1863]) by albert.telenet-ops.be with bizsmtp id 4GHn2C00Y4SDPei06GHosd; Thu, 28 Mar 2024 17:17:49 +0100 Importance: normal X-Priority: 3 In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=telenet.be; s=r24; t=1711642669; bh=B2yiVw2eA8Jylykia0M9ZnRQ3/94guebSwwLcs19rD8=; h=To:From:Subject:Date:In-Reply-To:References; b=dNO7gq+yQstMRwKP4VgaLNJipCKSVaWOGUTPepQWxK4aY0BBsxwvjOcKBuYWpnMS9 LwJykFS2CWiZfjoVuQIZ6nJULvF0TaKzJRHkkcpuSmaF9UyH0AEsVbQx5Ij5Fv5kLR 5tvBiIJIWCBOTrPeXyP6gztr0mj9IgHW440RZVszhm9wSehhYyfjIBnC5Ppudtv9+Z MuuL1LnC7hMlIPhBkT2RRVM/s0juxLNd2m/OWhEI77eomF+NqzaBesByu37ASNX0N4 jepjMBN+Uf6r9rKx4u/fYsNISgNhMli/cy6MQDNUUmdn2hKCFtyzE+pPS6h4xAawqL li+fgLSIdaEBg== Received-SPF: pass client-ip=2a02:1800:110:4::f00:1a; envelope-from=maximedevos@telenet.be; helo=albert.telenet-ops.be X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.devel:22377 Archived-At: --_F6E2AAE8-D773-4091-8ECD-BE6C315C055A_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" As mentioned previous e-mails, either: =E2=80=A2 the docstring forgets to mention that it is the caller=E2=80=99s = responsibility it is to check that =E2=80=98str=E2=80=99 is a valid method = name (and you need to check/adjust the callers to do the check, of which I = have seen n) =E2=80=A2 or 'parse-http-method=E2=80=99 is missing a check that (string-le= ngth str)>0 and the characters of str belong to tchar (defined in the RFC). Please do not ignore reviews when making PRs =E2=80=93 disagreeing with som= e review(s) and then mentioning in the commit message/cover letter/comments= /... as appropriate why you deviate from them is one thing, just acting as = if they didn=E2=80=99t happen is another. In the previous discussion I have heard an argument for not doing the check= , which basically amounts to flexibility for sake of flexibility in spite o= f potential security problems and in spite of the third option (i.e. with b= oth security and flexibility) of not allowing it by default and instead add= ing an argument somewhere to add a custom checker/list of extra allowed met= hods/... that defaults to what RFC specifies, but I haven=E2=80=99t heard a= n argument for not properly documenting that what parse-http-method parses = aren=E2=80=99t HTTP methods so the callers may need to do extra validation.= =20 Also, the commit message needs to be changed to changelog format. Also worth checking if the Texinfo documentation mentions parse-http-method= , and if so, adjust it. Best regards, Maxime Devos. --_F6E2AAE8-D773-4091-8ECD-BE6C315C055A_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

As mentioned pre= vious e-mails, either:

 

  • the docstring forgets to mention that it is t= he caller=E2=80=99s responsibility it is to check that =E2=80=98str=E2=80= =99 is a valid method name (and you need to check/adjust the callers to do = the check, of which I have seen n)
  • or 'parse-http-method=E2=80=99 is missing a check that (string-len= gth str)>0 and the characters of str belong to tchar (defined in the RFC= ).

 

Please do not ignore reviews when making PRs =E2=80=93 disagr= eeing with some review(s) and then mentioning in the commit message/cover l= etter/comments/... as appropriate why you deviate from them is one thing, j= ust acting as if they didn=E2=80=99t happen is another.

 

In the previous discussion I have heard = an argument for not doing the check, which basically amounts to flexibility= for sake of flexibility in spite of potential security problems and in spi= te of the third option (i.e. with both security and flexibility) of not all= owing it by default and instead adding an argument somewhere to add a custo= m checker/list of extra allowed methods/... that defaults to what RFC speci= fies, but I haven=E2=80=99t heard an argument for not properly documenting = that what parse-http-method parses aren=E2=80=99t HTTP methods so the calle= rs may need to do extra validation.

 

Also, the commit message needs to be changed to changelog f= ormat.

&n= bsp;

Also worth che= cking if the Texinfo documentation mentions parse-http-method, and if so, a= djust it.

 

Best regard= s,

Maxime Devo= s.

= --_F6E2AAE8-D773-4091-8ECD-BE6C315C055A_--