[GH-ISSUE #358] Directories are represented as files due to incomplete Content-Type parsing #181

New issue

Closed

opened 2026-03-04 01:43:02 +03:00 by kerem · 1 comment

kerem commented

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

Owner

Originally created by @yurykats on GitHub (Feb 8, 2016).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/358

When using s3fs with an S3-compatible storage provider, I came across a problem with directory representation. Directories were being represented as 0-byte files.

This happened because the storage provider returns Content-Type header with a charset parameter, eg Content-Type: application/octet-stream;charset=ISO-8859-1

s3fs_util.cpp does a literal comparison of the Content-Type header to predefined values, and thus fails, if the header contains optional charset parameter

if(meta.end() != (iter = meta.find("Content-Type"))){
            string strConType = (*iter).second;
            if(strConType == "application/x-directory"){
              mode |= S_IFDIR;
            }else if(path && 0 < strlen(path) && '/' == path[strlen(path) - 1]){
              if(strConType == "binary/octet-stream" || strConType == "application/octet-stream"){
                mode |= S_IFDIR;
              }else{
                mode |= S_IFREG;
              }
            }else{
              mode |= S_IFREG;
            }
          }else{
            mode |= S_IFREG;
          }

The charset parameter inside the Content-Type header is perfectly legal both from HTTP and S3 point of view. S3 spec even shows it in its own example: http://docs.aws.amazon.com/AmazonS3/latest/API/RESTCommonResponseHeaders.html

Content-Type The MIME type of the content. For example, Content-Type: text/html; charset=utf-8

The code that parses the Content-Type header in s3fs_util.cpp should only consider the value up to the semi-colon.

Originally created by @yurykats on GitHub (Feb 8, 2016). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/358 When using s3fs with an S3-compatible storage provider, I came across a problem with directory representation. Directories were being represented as 0-byte files. This happened because the storage provider returns Content-Type header with a charset parameter, eg Content-Type: application/octet-stream;charset=ISO-8859-1 s3fs_util.cpp does a literal comparison of the Content-Type header to predefined values, and thus fails, if the header contains optional charset parameter ``` if(meta.end() != (iter = meta.find("Content-Type"))){ string strConType = (*iter).second; if(strConType == "application/x-directory"){ mode |= S_IFDIR; }else if(path && 0 < strlen(path) && '/' == path[strlen(path) - 1]){ if(strConType == "binary/octet-stream" || strConType == "application/octet-stream"){ mode |= S_IFDIR; }else{ mode |= S_IFREG; } }else{ mode |= S_IFREG; } }else{ mode |= S_IFREG; } ``` The charset parameter inside the Content-Type header is perfectly legal both from HTTP and S3 point of view. S3 spec even shows it in its own example: http://docs.aws.amazon.com/AmazonS3/latest/API/RESTCommonResponseHeaders.html Content-Type The MIME type of the content. For example, Content-Type: text/html; charset=utf-8 The code that parses the Content-Type header in s3fs_util.cpp should only consider the value up to the semi-colon.