Opened 12 years ago

Closed 11 years ago

Last modified 11 years ago

#36 closed enhancement (wontfix)

Feature Request - Support Filtering Requests by mimetype

Reported by: Kory Prince Owned by: somebody
Priority: minor Milestone:
Component: other Version: 1.1.x
Keywords: mimetype content-type Cc:
uname -a: N/A
nginx -V: N/A

Description

It would be really advantageous to filter requests like we do with location using mimetypes.
As an example:

mimetype image/png {

expire 3h;

}

Multiple mimetypes:

mimetype image/* text/html {

404;

}

The main reason to do this is for setting expiry explicitly for different content types.
For now, we rely on using location to specify by extension, but this can be problematic when using cgi, because sometimes the url doesn't contain the extension, and there is no way to separate out content types.

There are, of course, other reasons to do this. Perhaps to deny certain file types from being sent, even when they don't contain a correct (or any) file extension.

Obviously, since we would want this to work for fastcgi, etc, it would have to run *after* we receive the response from upstream.

Change History (3)

comment:1 by Maxim Dounin, 11 years ago

Resolution: wontfix
sensitive: 0
Status: newclosed

Modules which need mime-type based filtering are expected to do this via appropriate controls, like gzip_types. Additionally, mime type can be checked with generic conditional processing mechanisms like map. There are no plans to implement additional mime-type based generic mechanisms.

comment:2 by Kory Prince, 11 years ago

I don't see how either of those would help this problem. Perhaps you can elaborate.

For instance if a request of:

"/style"

goes to an upstream source which returns a content type of "text/css", how could I filter that? (Based on the response content-type.)

comment:3 by Maxim Dounin, 11 years ago

Response content type is available in $sent_http_content_type variable, and to filter based on it you may use map{}. E.g.

map $sent_http_content_type $is_css {
    default 0;
    text/css 1;
}

location / {
    add_header X-Test $is_css;
    return 200 "";
}

This way it would be nontrivial to specify expiration as "expires" directive doesn't understand variables, but this is another question (which probably needs addressing, but certainly not with a mechanism proposed in this ticket).

Note: See TracTickets for help on using tickets.