return Content-Disposition header alongside content

[acud]

The HTTP server should return a Content-Disposition Header alongside with content so that browsers/http clients could know how to save a file.

The server should determine the filename according to what's in the path section of the URI/Manifest path entry, or fall back to the content hash at worst case.

e.g. Content-Disposition: attachment; filename="filename.jpg"

[nizsheanez]

I would like to take this ticket.

A bit investigated:

• Chrome doesn't respect Content-Disposition header if Content-Type header is absent (FireFox does)
• default swarm up /path/to/example.md calling swarm/api.UploadTar which save empty ContentType. There are hdr.Xattrs and hdr.PAXRecords have empty content type value.

Will discover more tomorrow.

[acud]

@nizsheanez you can have it :) please join our gitter channel for any questions that might arise.

[nizsheanez]

Thank you.

Here is the reason:

• I did upload .md file
• cmd/swarm.detectMimeType did try detect ContentType by the file extension, but had no success because .md extension is not in mime.builtinTypesLower map. And cmd/swarm.detectMimeType returned empty string

But:

• http 1.1 rfc require fallback to "application/octet-stream": If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream" - https://tools.ietf.org/html/rfc2616#section-7.2

Good news - cmd/swarm.detectMimeType using http.DetectContentType which already follow fallback to "application/octet-stream".
I will change cmd/swarm.detectMimeType behavior: if detection by file extension return empty string - it will try content-based detection by http.DetectContentType

Do i need change swarm/api.Get to return "application/octet-stream" if mimeType is empty?

[acud]

@nizsheanez correct; I opened a related issue yesterday (for different reasons) about the topic - that we should switch to magic-number based MIME type detection and dump the extension based detection. it is also not being used properly for when uploading a directory. see #944

both should use magic number detection.

I think that for one thing - the uploading code should be fixed to fall back to octet-stream, then surely there has to be a fallback on the api/http package (not sure if api should care about MIME types). We can start with this and observe the results.

[nizsheanez]

Created PR about Content-Disposition first:
#945

Also, looks like need to review all places where expected "Content-Type" of file from client and:

• add Validation by mime.ParseMediaType(r.Header.Get("Content-Type"))
• If "Content-Type" is empty/not-sent-by-client fallback to "application/octet-stream"
  For example in api/http.handleDirectUpload: https://github.com/ethersphere/go-ethereum/blob/master/swarm/api/http/server.go#L422

btw, is that ok that i keeping discussion here instead of Gitter? In my head - Gitter for some common questions.

[acud]

Sure let's keep the conversation here.

Adding the validation is a good idea - go for it. Same for fallbacks.

You should be able to cover everything from the http package and the upload.go file - these are the relevant entry points for mime.

The rest of the codebase only cares about mime types in the context of manifest traversals - which in this case looks for an application/bzz-manifest+json content type in order to continue traversing a manifest trie, and this is the only case you should watch out for (although I just checked that mime.ParseMediaType("application/bzz-manifest+json") passes and does not throw an error - so we should be good with this).

[nizsheanez]

Done