Both go and js clients send "Content-Disposition: file;" when adding files

[vasild]

Version information:

$ ipfs-go version --all
go-ipfs version: 0.4.3-6828105
Repo version: 4
System version: amd64/freebsd
Golang version: go1.7.1

Type:

Bug

Priority:

P5

Description:

Both go and js clients, when adding files, send a wrong Content-Disposition value - "file", whereas it should be "form-data" according to http://www.ietf.org/rfc/rfc2388.txt.

For example:
$ ipfs-go --api=/ip4/127.0.0.1/tcp/50011 add foo.txt
sends this to the server:

POST /api/v0/add?encoding=json&progress=true&stream-channels=true HTTP/1.1
Host: 127.0.0.1:50011
User-Agent: /go-ipfs/0.4.3/
Connection: close
Transfer-Encoding: chunked
Content-Type: multipart/form-data; boundary=5920957780ad1603c2973b3f719d582e14f5bdb1886e9e91962293839b2a
Accept-Encoding: gzip

1
-
98
-5920957780ad1603c2973b3f719d582e14f5bdb1886e9e91962293839b2a
Content-Disposition: file; filename="foo.txt"
Content-Type: application/octet-stream


5
abcd

44

--5920957780ad1603c2973b3f719d582e14f5bdb1886e9e91962293839b2a--

0

and this Node.js client:

var files = [
  {
    path: '/tmp/f1.txt',
    content: "f1f1f1"
  },
  {
    path: '/tmp/f2.txt',
    content: "f2f2f2"
  }
]
ipfs.files.add(files, function (err, files_result) {
  for (var i = 0; i < files_result.length; i++) {
    console.log(i);
    console.log(files_result[i]);
  }
})

sends:

POST /api/v0/add?recursive=true&stream-channels=true HTTP/1.1
User-Agent: /node-ipfs-api/9.0.0/
Content-Type: multipart/form-data; boundary=3iaze957b0h1de3s98rqf47vi
Host: localhost:50011
Connection: close
Transfer-Encoding: chunked

1d
--3iaze957b0h1de3s98rqf47vi

63
Content-Disposition: file; filename="/tmp/f1.txt"
Content-Type: application/octet-stream

f1f1f1
1f

--3iaze957b0h1de3s98rqf47vi
...

According to RFC2388 it should be "Content-Disposition: form-data;"

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition has some examples.

[whyrusleeping]

Hrm... is there a compelling reason to use form-data? at the end of the day its just a string constant, right?

[vasild]

A reason could be to comply to the HTTP specification. From https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition : "Only the value form-data, as well as the optional directive name and filename, can be used in the HTTP context".

I could have misread the specs. Feel free to close this issue if sending "Content-Disposition: file;" is not a violation.

[whyrusleeping]

@dignifiedquire what do you think?

[dignifiedquire]

Reading the spec the file value is actually correct in most cases, just in the single file case. Often times add is used to send multiple files and then content-disposition: file" is the right value.

The original local file name may be supplied as well, either as a
"filename" parameter either of the "content-disposition: form-data"
header or, in the case of multiple files, in a "content-disposition:
file" header of the subpart.

We could change the case of a single file, but if there are no issues with it, I doubt it's worth it.

[soapdog]

@dignifiedquire if the developer uses the fetch() alongside the new FormData() to generate the body of the request, the browser will use content-disposition: form-data and there is no API to change that. I couldn't find an API on MDN WebDocs to create a request with content-disposition: file.

[Stebalien]

go-ipfs now sends the correct content disposition (form-data) and doesn't really care what the client sends.

I've filed a bug against js-ipfs: ipfs-inactive/js-ipfs-http-client#1072