[GH-ISSUE #481] Content-Type set to application/octet-stream during recursive copy #268

New issue

Closed

opened 2026-03-04 01:43:54 +03:00 by kerem · 2 comments

kerem commented

2026-03-04 01:43:54 +03:00

Owner

Originally created by @cowmix88 on GitHub (Oct 10, 2016).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/481

I'm moving some javascript files from some nested folders onto an s3fs mount. If I don't use the recursive flag "-r" then the files have the Content-Type marked correctly was "text/javascript" but as soon as I use recursive flag to also copy over the nested folders and their files all files get marked as application/octet-stream.

Originally created by @cowmix88 on GitHub (Oct 10, 2016). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/481 I'm moving some javascript files from some nested folders onto an s3fs mount. If I don't use the recursive flag "-r" then the files have the Content-Type marked correctly was "text/javascript" but as soon as I use recursive flag to also copy over the nested folders and their files all files get marked as application/octet-stream.

kerem

2026-03-04 01:43:54 +03:00

closed this issue
added the
question
label

kerem commented

2026-03-04 01:43:55 +03:00

Author

Owner

@cowmix88 commented on GitHub (Oct 10, 2016):

Ah I found the issue it looks like its because these files are actually links instead of the actual file. S3Fs looks up the content-type of the link itself instead of the target file resulting in the wrong Content-Type. Is there a way to make S3FS use the content type of the link target?

@cowmix88 commented on GitHub (Oct 10, 2016): Ah I found the issue it looks like its because these files are actually links instead of the actual file. S3Fs looks up the content-type of the link itself instead of the target file resulting in the wrong Content-Type. Is there a way to make S3FS use the content type of the link target?

kerem commented

2026-03-04 01:43:55 +03:00

Author

Owner

@ggtakec commented on GitHub (May 5, 2017):

@cowmix88 I'm very sorry for late my reply.
The content type of the symbolic link is application/octet-stream.
If you want to change the content-type for this symbolic link, specifying the ahbe_conf option is the only way to do it.
Please refer to the test/sample_ahbe.conf file and describe the following contents and specify it in the ahbe_conf option.

.js     Content-Type   text/javascript

Thus, even if the *.js is a symbolic link, the content-type will be text/javascript.

I'm closing this issue, but if you have more question, please reopen this issue.
Regards,

@ggtakec commented on GitHub (May 5, 2017): @cowmix88 I'm very sorry for late my reply. The content type of the symbolic link is application/octet-stream. If you want to change the content-type for this symbolic link, specifying the ahbe_conf option is the only way to do it. Please refer to the test/sample_ahbe.conf file and describe the following contents and specify it in the ahbe_conf option. ``` .js Content-Type text/javascript ``` Thus, even if the *.js is a symbolic link, the content-type will be text/javascript. I'm closing this issue, but if you have more question, please reopen this issue. Regards,

kerem referenced this issue

2026-03-04 01:53:58 +03:00

[PR #268] [MERGED] Use 127.0.0.1 not localhost in s3proxy wait loop #1436