Rclone serve http "save as"

Help and Support
1

What is the problem you are having with rclone?

When serving m4a files on http or webdav the "right click" -> "save link as"* procedure give out a mp3 file. One has to manually change the extention to m4a.
Tested in Chrome, Vivaldi and Edge, I get the same behaviour in all three of them.
Am I missing something in the configuration of the serve command ?

*I'm not sure how this is stated in English, it is "Enregistrer le lien sous..." in French in Chrome.

What is your rclone version (output from rclone version)

C:\Users\danbei>rclone version
rclone v1.56.1
- os/version: Microsoft Windows 10 Pro 2009 (64 bit)
- os/kernel: 10.0.19042.1202 (x86_64)
- os/type: windows
- os/arch: amd64
- go/version: go1.16.8
- go/linking: dynamic
- go/tags: cmount

Which cloud storage system are you using? (eg Google Drive)

I use local remote in this example

The command you were trying to run (eg rclone copy /tmp remote:tmp)

mkdir foo
type nul > foo/bar.m4a
rclone -vv serve http foo/

The rclone config contents with secrets removed.

No config file is provided to rclone in this example.

A log from the command with the -vv flag

C:\Users\danbei>rclone -vv serve http foo/
2021/09/23 23:05:49 DEBUG : rclone: Version "v1.56.1" starting with parameters ["rclone" "-vv" "serve" "http" "foo/"]
2021/09/23 23:05:49 DEBUG : Creating backend with remote "foo/"
2021/09/23 23:05:49 NOTICE: Config file "C:\\Users\\danbei\\AppData\\Roaming\\rclone\\rclone.conf" not found - using defaults
2021/09/23 23:05:49 DEBUG : fs cache: renaming cache item "foo/" to be canonical "//?/C:/Users/danbei/foo"
2021/09/23 23:05:49 INFO  : Local file system at //?/C:/Users/danbei/foo: poll-interval is not supported by this remote
2021/09/23 23:06:13 INFO  : : 127.0.0.1:51181: Serving directory
2021/09/23 23:06:16 DEBUG : bar.m4a: Open: flags=O_RDONLY
2021/09/23 23:06:16 DEBUG : bar.m4a: >Open: fd=bar.m4a (r), err=<nil>
2

That seems to be a browser thing and nothing related to rclone.

You can validate with wget:

etexter@seraphite Downloads % wget http://localhost:8989/bar.m4a
--2021-09-23 17:24:38--  http://localhost:8989/bar.m4a
Resolving localhost (localhost)... ::1, 127.0.0.1
Connecting to localhost (localhost)|::1|:8989... connected.
HTTP request sent, awaiting response... 200 OK
Length: 14 [audio/mpeg]
Saving to: ‘bar.m4a’

bar.m4a                                     100%[==========================================================================================>]      14  --.-KB/s    in 0s

2021-09-23 17:24:38 (2.23 MB/s) - ‘bar.m4a’ saved [14/14]

As I get the same behavior in Chrome.

3

Indeed no problem with wget in WSL :

$ wget http://localhost:8080/bar.m4a
--2021-09-23 23:32:38--  http://localhost:8080/bar.m4a
Resolving localhost (localhost)... 127.0.0.1
Connecting to localhost (localhost)|127.0.0.1|:8080... connected.
HTTP request sent, awaiting response... 200 OK
Length: 0 [audio/mpeg]
Saving to: ‘bar.m4a’

bar.m4a                           [ <=>                                              ]       0  --.-KB/s    in 0s

2021-09-23 23:32:38 (0.00 B/s) - ‘bar.m4a’ saved [0/0]

There is no problem downloading the file via the browser neither, it is just that the extension is changed (see 1st screen shot attached below). I'm confused because I don't get this behaviour with other http servers (see 2nd screen shot attached below).

Note that I noticed an extension change only for m4a files. I tested wav, flac, mp3 and mp4 files.

Served by rclone

rclone_serve_http
rclone_serve_http767×921 50.3 KB

Served by some apache server

rclone_serve_http
rclone_serve_http825×896 69.4 KB

4

If you check the browser's developer tools, does the working server return relevant headers, e.g. Content-Type, Content-Disposition, that rclone serve does not?

5

Here is the code of the page served by the working server, I only removed the paths. I don't know enough about html to know what to look for.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
  <head>
    <title>Index of /***/***/foo</title>
  </head>
  <body>
    <h1>Index of /***/***/foo</h1>
    <pre><img src="/***/blank.gif" alt="Icon "> <a href="?C=N;O=D">Name</a>                    
      <a href="?C=M;O=A">Last modified</a>      
      <a href="?C=S;O=A">Size</a>  
      <a href="?C=D;O=A">Description</a>
      <hr>
        <img src="/***/back.gif" alt="[PARENTDIR]"> 
        <a href="/***/***/">Parent Directory</a>                             -   
        <img src="/***/unknown.gif" alt="[   ]"> 
        <a href="bar.m4a">bar.m4a</a>
        2021-09-23 23:47    0
      <hr>
    </pre>
  </body>
</html>

When I copy the html source of the page served by rclone into a file and open the file in my browser the behaviour is correct : m4a file are downloaded as m4a.

I can copy the source of the page served by rclone if needed.

6

I can reproduce the issue.

It is related to this code:

The case is that if the backend does not supply MIME information, like local filesystem, as listed here, then serve http will use the file extension and lookup in a os dependent mime database. In my test it ends up with audio/mpeg, and based on that the browser apparantly deduces .mp3 extension.

Haven't checked what mime type a working system reports, but probably audio/x-m4a og audio/mp4 or something.

This needs some more investigation...

7

Found the problem, think it is a bug, suggested fix here.

1 Like
8

Great ! thank you for your responsiveness

9

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.