GNU bug report logs - #20469
mm-url-encode-multipart-form-data: allow for text/plain and application/octet-stream parts

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 20469 in the body.
You can then email your comments to 20469 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ivan Shmakov <ivan <at> siamics.net>
To: submit <at> debbugs.gnu.org
Subject: mm-url-encode-multipart-form-data: allow for text/plain and
 application/octet-stream parts 
Date: Thu, 30 Apr 2015 14:40:13 +0000

Package:  emacs
Severity: wishlist

	As it seems, mm-url-encode-multipart-form-data currently
	(1c7f0cdc4c1f, 2015-04-27 16:59:11 +00:00) supports only parts
	encoded via mm-url-form-encode-xwfu – even though RFC 1867
	clearly shows that text/plain and application/octet-stream are
	also valid options.

	For one thing, the ‘upload’ MediaWiki API function depends on
	multipart/form-data POST requests, /and/ seem to choke upon text
	encoded via mm-url-form-encode-xwfu.  Hence, Emacs
	implementation of the client side of said API cannot use the
	function in its current form, and would benefit from one capable
	of encoding text/plain parts.

[1] http://www.mediawiki.org/wiki/API:Upload

-- 
FSF associate member #7257  http://am-1.org/~ivan/      … 3013 B6A0 230E 334A

Message #8 received at 20469 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Ivan Shmakov <ivan <at> siamics.net>
Cc: 20469 <at> debbugs.gnu.org
Subject: Re: bug#20469: mm-url-encode-multipart-form-data: allow for
 text/plain and application/octet-stream parts
Date: Fri, 25 Dec 2015 19:17:00 +0100

Ivan Shmakov <ivan <at> siamics.net> writes:

> 	For one thing, the ‘upload’ MediaWiki API function depends on
> 	multipart/form-data POST requests, /and/ seem to choke upon text
> 	encoded via mm-url-form-encode-xwfu.  Hence, Emacs
> 	implementation of the client side of said API cannot use the
> 	function in its current form, and would benefit from one capable
> 	of encoding text/plain parts.

How would one decide whether to use xwfu encoding or not?  I'm not
terribly familiar with that code, but it doesn't seem to have many...
er...  inputs...  to allow it to determine that.

But I'm probably missing something...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #11 received at 20469 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Ivan Shmakov <ivan <at> siamics.net>
Cc: 20469 <at> debbugs.gnu.org
Subject: Re: bug#20469: mm-url-encode-multipart-form-data: allow for
 text/plain and application/octet-stream parts 
Date: Fri, 28 May 2021 02:24:10 +0200

Ivan Shmakov <ivan <at> siamics.net> writes:

> 	As it seems, mm-url-encode-multipart-form-data currently
> 	(1c7f0cdc4c1f, 2015-04-27 16:59:11 +00:00) supports only parts
> 	encoded via mm-url-form-encode-xwfu – even though RFC 1867
> 	clearly shows that text/plain and application/octet-stream are
> 	also valid options.

As far as I can tell, this was fixed in:

commit a6e0188dffc394698d9ffbef50401f14a31c8722
Author:     Lars Ingebrigtsen <larsi <at> gnus.org>
AuthorDate: Thu Oct 13 21:39:29 2016 +0200

So I'm closing this bug report.  If this is still a problem, please
respond to the debbugs address and we'll reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.