Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default content-type for StaticFiles #1397

Closed
pwoolcoc opened this issue Jul 30, 2020 · 4 comments
Closed

Default content-type for StaticFiles #1397

pwoolcoc opened this issue Jul 30, 2020 · 4 comments
Labels
accepted An accepted request or suggestion help wanted Contributions to this issue are needed request Request for new functionality

Comments

@pwoolcoc
Copy link

Rocket version:

version = "0.5.0-dev"
source = "git+https://github.com/SergioBenitez/rocket#ddfd73d6f33e8a8ef3f37be94bbbdcb840804326"

os version: OSX Catalina (10.15.6)

When using StaticFiles to serve content, it relies on ContentType::from_extension to generate the content-type header for a response. If a file does not have an extension, no content-type will be set. I'd like to know if there is a way to set a default content-type, or if that would be a useful feature to add. I'm willing to open a PR for the feature if there is a likely chance it will be accepted.

To reproduce: serve a file without an extension using rocket_contrib::serve::StaticFiles

Assuming there is no existing way to do this, I'd be curious about maintainers' ideas of how to solve this. I'd be happy defaulting to text/plain, and including it as an option in the existing Options bitmask. However, others might want the ability to set it to a specific content-type, like text/html or something else, and in that case I don't have a great idea for a design.

@igalic
Copy link

igalic commented Jul 30, 2020

maybe one could provide a default content type via Rocket.toml? although i don't know how much of that would change with #852

@SergioBenitez SergioBenitez added the request Request for new functionality label Aug 1, 2020
@SergioBenitez
Copy link
Member

When using StaticFiles to serve content, it relies on ContentType::from_extension to generate the content-type header for a response. If a file does not have an extension, no content-type will be set. I'd like to know if there is a way to set a default content-type, or if that would be a useful feature to add. I'm willing to open a PR for the feature if there is a likely chance it will be accepted.

There is no way to set a default Content-Type at the moment. My take is that a good default would be ContentType::Binary, or perhaps None as it is today. Here's an idea for an API:

impl StaticFiles {
    pub fn default_content_type<C>(mut self, content_type: C) -> Self 
        where C: Into<Option<ContentType>>
    {
        self.default_content_type = content_type.into();
        self
    }
}

.default_content_type(None) would revert the functionality to the present one. .default_content_type(ContentType::Plain), for example, would set ContentType::Plain as the default Content-Type.

I would accept a PR implementing this API. It's unfortunate that default_content_type is rather lengthy; I'd be appreciative of a name that is as descriptive yet pithier.

@SergioBenitez SergioBenitez added the accepted An accepted request or suggestion label Aug 1, 2020
@SergioBenitez
Copy link
Member

@igalic With #852 implemented, you could parse your own Content-Type from a config easily:

# Rocket.toml
default_content_type = "application/json"
#[derive(Deserialize)]
struct MyAppConfig {
    default_content_type: ContentType
}

let config: MyAppConfig = Config::default().extract()?;
rocket::ignite().mount("/", StaticFiles::from(...).default(config.default_content_type));

@SergioBenitez SergioBenitez added the help wanted Contributions to this issue are needed label Aug 2, 2020
@SergioBenitez
Copy link
Member

Accepted, and moving to tracking in #95.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepted An accepted request or suggestion help wanted Contributions to this issue are needed request Request for new functionality
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants