From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: ozzloy Newsgroups: gmane.emacs.bugs Subject: bug#63941: [PATCH] ; always CRLF before non-first boundary in multipart form Date: Wed, 7 Jun 2023 19:48:29 -0700 Message-ID: References: <837csf4fp8.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000008c368905fd954a11" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23520"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 63941@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jun 08 06:31:49 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1q77JN-0005uV-3g for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 08 Jun 2023 06:31:49 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q77In-0006os-9z; Thu, 08 Jun 2023 00:31:13 -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 1q77If-0006nh-J7 for bug-gnu-emacs@gnu.org; Thu, 08 Jun 2023 00:31:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q77If-0000QE-9q for bug-gnu-emacs@gnu.org; Thu, 08 Jun 2023 00:31:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q77If-0007lC-65 for bug-gnu-emacs@gnu.org; Thu, 08 Jun 2023 00:31:05 -0400 X-Loop: help-debbugs@gnu.org Resent-From: ozzloy Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 08 Jun 2023 04:31:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63941 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 63941-submit@debbugs.gnu.org id=B63941.168619866129765 (code B ref 63941); Thu, 08 Jun 2023 04:31:05 +0000 Original-Received: (at 63941) by debbugs.gnu.org; 8 Jun 2023 04:31:01 +0000 Original-Received: from localhost ([127.0.0.1]:55361 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q77IZ-0007jv-V5 for submit@debbugs.gnu.org; Thu, 08 Jun 2023 00:31:00 -0400 Original-Received: from mail-oo1-f46.google.com ([209.85.161.46]:42176) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q75hk-00007q-8U for 63941@debbugs.gnu.org; Wed, 07 Jun 2023 22:48:55 -0400 Original-Received: by mail-oo1-f46.google.com with SMTP id 006d021491bc7-55afa2472d9so133856eaf.0 for <63941@debbugs.gnu.org>; Wed, 07 Jun 2023 19:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686192526; x=1688784526; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=abFGWv9Zm2lxmua26DOktdS6qhkZmJ9Hqiz9DPx0FT8=; b=Fhb/Y8i8ktqsQR00fAH4qsWwiUEFIn5XO2I5OTXqEvdgKl52M9VePiNTjWwBrm1tZ/ MvsqSJWqG7PaEzzl1pFk57zHp0N0ME7yLVEKpprbkM7B7W3gDXTJOqUnzgoQGpeXNqg2 icmX0q+ntEDMuAIs4l32Kla3viXdVYuHwdY3mCtY4mDh/TMhFvbGc569fhsioOUA/4LS sDeZDMBbSZ6a8A7VlB2rVs0IYiigJxqFiZvgzuat6nLtPRLQapD41E2xvj3qB1Q2I8/f Hpto/d50EVzav40WgJ9aYlEhlMshHiyKXbLIPAig1JUYQYYPCH+pYu3fK3RK/0iGqpnB ylLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686192526; x=1688784526; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=abFGWv9Zm2lxmua26DOktdS6qhkZmJ9Hqiz9DPx0FT8=; b=d0czaQ6ausu2So5KGTKkcUkjXqXWcsNs/eGnCj8nFLQGm6v8n38JqUyvtGg+SNfdbK F+z3YbNN3GbaxGutF/kE1mAqI+OBW/EkdpZPiqgDPQ0H0AyMmoxqHoaePPd0+ogYWnk3 d4Q6jgJQ23EGIX5FWDtUtSDdOEBmr4S+npNmuan+1W3V/I2e0oPevZLdBDYcBIvgIpbv uOEdfPI+tHlFwqt9ymw9IbBD7KT+DhBoZXXDQlS4fqkaOvxgOxiwCPwfEPoWDGLrwztM pFaLSDtJDEZulMPgAY5aJo+UIRWNvIPP1Vdbv72OfJZ6LboA/Q8WJTam7s32bXMjEg4+ ebXw== X-Gm-Message-State: AC+VfDybHFmx+wruKVFodNDakMq0kZkHdD/JO6aNwpqKBxiyLHMw1Npr n5d7OZln8RY51wiCDIF5qIGXjcHIbVHKgarWXoI= X-Google-Smtp-Source: ACHHUZ6k26AynwhA9CeZfKkjD+fCrTO5cCSJPtrry6OFJmymNWjD9HvLitkWH/Koo28rfvBz335aq9fiyuU5rCFptDQ= X-Received: by 2002:a05:6820:1050:b0:55b:2dda:84bd with SMTP id x16-20020a056820105000b0055b2dda84bdmr421760oot.1.1686192526209; Wed, 07 Jun 2023 19:48:46 -0700 (PDT) In-Reply-To: <837csf4fp8.fsf@gnu.org> X-Mailman-Approved-At: Thu, 08 Jun 2023 00:30:50 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:263097 Archived-At: --0000000000008c368905fd954a11 Content-Type: text/plain; charset="UTF-8" > please describe in detail what should be done Sure! I'm not sure what would be too much, and what would be too little explanation. The short version is to run the following code, #+begin_src elisp (require 'mm-url) (let ((data '(("file" ("filedata" . "file content\n") ("name" . "file") ("filename" . "filename")))) (boundary "BOUNDARY")) (mm-url-encode-multipart-form-data data boundary)) #+end_src #+RESULTS: : --BOUNDARY^M : Content-Disposition: form-data; name="file"; filename="filename"^M : Content-Transfer-Encoding: binary^M : Content-Type: text/plain^M : ^M : file content : --BOUNDARY--^M (I've replaced carriage returns with literal '^' and 'M' to avoid email mangling) and observe the absence of CRLF between the file content and the boundary. >From https://www.rfc-editor.org/rfc/rfc2046#section-5.1.1 this description, it seems like there should be. Here's a longer set of steps. 0. run http server #+begin_src bash git clone https://git.sr.ht/~ozzloy/emacs-bug-63941 cd emacs-bug-63941 git checkout reproduce-bug-63941 ./server.py #+end_src 1. Then use EWW to browse to localhost:8085 and upload the file =filename=. Here's my result when doing that, first with EWW. #+begin_quote upload_content = b'file content', name = 'filename', size = 12 127.0.0.1 - - [07/Jun/2023 18:55:03] "POST / HTTP/1.1" 200 - #+end_quote The bug is that the file content no longer has the final "\n". 2. To confirm, in a separate shell, I posted using curl. #+begin_src bash curl -F "file=@filename;filename=filename" localhost:8085 #+end_src Here's the output I got #+begin_quote upload_content = b'file content\n', name = 'filename', size = 13 127.0.0.1 - - [07/Jun/2023 18:57:12] "POST / HTTP/1.1" 200 - #+end_quote The file's content ends with "\n", which is the expected behavior. This is the second HTTP file upload server I have used and seen this behavior. The same thing happened for one I wrote in clojure using Aleph. That one is here https://git.sr.ht/~ozzloy/fupload but I made the python one because it's probably less set up for other people to reproduce it. --0000000000008c368905fd954a11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> please describe in detail what should be done

= Sure!=C2=A0 I'm not sure what would be too much, and what would be too = little
explanation.

The short version is to run the following cod= e,
#+begin_src elisp
(require 'mm-url)
(let ((data '((&quo= t;file"
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 ("filedata" . "file content\n")=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 ("name"=C2=A0=C2=A0=C2=A0=C2=A0 . "file")
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= ("filename" . "filename"))))
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 (boundary "BOUNDARY"))
=C2=A0 (mm-url-encode-multipa= rt-form-data data boundary))
#+end_src

#+RESULTS:
: --BOUNDARY= ^M
: Content-Disposition: form-data; name=3D"file"; filename= =3D"filename"^M
: Content-Transfer-Encoding: binary^M
: Con= tent-Type: text/plain^M
: ^M
: file content
: --BOUNDARY--^M
(I= 've replaced carriage returns with literal '^' and 'M' = to avoid email
mangling)

and observe the absence of CRLF between = the file content and the boundary.
From https://www.rfc-editor.org/rfc/rfc2046#sec= tion-5.1.1 this description,
it seems like there should be.

H= ere's a longer set of steps.

0. run http server
#+begin_src b= ash
=C2=A0 git clone https://git.sr.ht/~ozzloy/emacs-bug-63941
=C2=A0 cd emacs-bug-639= 41
=C2=A0 git checkout reproduce-bug-63941
=C2=A0 ./server.py
#+en= d_src

1. Then use EWW to browse to localhost:8085 and upload the fil= e =3Dfilename=3D.

Here's my result when doing that, first with E= WW.
#+begin_quote
upload_content =3D b'file content', name = =3D 'filename', size =3D 12
127.0.0.1 - - [07/Jun/2023 18:55:03]= "POST / HTTP/1.1" 200 -
#+end_quote

The bug is that th= e file content no longer has the final "\n".

2. To confirm= , in a separate shell, I posted using curl.
#+begin_src bash
=C2=A0 c= url -F "file=3D@filename;filename=3Dfilename" localhost:8085
#= +end_src

Here's the output I got
#+begin_quote
upload_cont= ent =3D b'file content\n', name =3D 'filename', size =3D 13=
127.0.0.1 - - [07/Jun/2023 18:57:12] "POST / HTTP/1.1" 200 -<= br>#+end_quote

The file's content ends with "\n", whic= h is the expected behavior.

This is the second HTTP file upload serv= er I have used and seen this
behavior. The same thing happened for one I= wrote in clojure using
Aleph. That one is here https://git.sr.ht/~ozzloy/fupload but I made the<= br>python one because it's probably less set up for other people to
= reproduce it.

--0000000000008c368905fd954a11--