Invalid content types served when using alias

[Vladimir Shebordaev]

Hi!

Well, just in case, this inlined version of ngx_http_set_exten() 
function seems to set r->exten in non-intrusive way when it is 
not known from URI but can be obtained from the file redirect path

Index: src/http/modules/ngx_http_static_module.c
===================================================================
--- src/http/modules/ngx_http_static_module.c	(revision 4892)
+++ src/http/modules/ngx_http_static_module.c	(working copy)
@@ -224,6 +224,24 @@
          return NGX_HTTP_INTERNAL_SERVER_ERROR;
      }

+    if (!r->exten.len) {
+        last = path.data + path.len - 1;
+        while (last > path.data + 1) {
+            if (last[-1] == '.' && last[-2] != '/') {
+
+                r->exten.data = last;
+                r->exten.len = path.len - (last - path.data);
+
+                break;
+
+            } else if (last[-1] == '/') {
+                break;
+            }
+
+            last--;
+        }
+    }
+
      if (ngx_http_set_content_type(r) != NGX_OK) {
          return NGX_HTTP_INTERNAL_SERVER_ERROR;
      }

This way, the MIME type guessed from the file redirect extension 
is sent to client instead of the default one, when it is not 
known from the original URI.

Otherwise, I'd suggest to update an 'alias' directive 
documentation to explicitly state that the default MIME type is 
used when it can not be guessed from the original location URI 
even if it is a file alias.

Hope it helps.

Regards,
Vladimir

On 24.10.2012 18:32, Maxim Dounin wrote:
> Hello!
>
> On Wed, Oct 24, 2012 at 05:59:33PM +0400, Vladimir Shebordaev wrote:
>
>> Hi!
>>
>> On 24.10.2012 03:50, Tom van der Woerdt wrote:
>>> Hi all,
>>>
>>> I'm using nginx' locations to serve a javascript file on '/client' :
>>>
>>>      location = /client {
>>>          expires epoch;
>>>          alias /path/to/a/file.js;
>>>      }
>>>
>>> Works fine, with one major exception: it gets an octet-stream
>>> Content-Type header.
>>
>> This is due to a bug in static module, it doesn't properly set
>> r->exten in this case, so the redirect gets default mime-type.
>
> As already explained by Igor, this is not a bug, but intentional
> behaviour.
>
> Extension as seen in the URI is used to determine mime type, not
> one on the file system (which might not be present at all).
>
>>
>> Please try this patch
>>
>> Index: src/http/modules/ngx_http_static_module.c
>> ===================================================================
>> --- src/http/modules/ngx_http_static_module.c	(revision 4892)
>> +++ src/http/modules/ngx_http_static_module.c	(working copy)
>> @@ -224,6 +224,9 @@
>>           return NGX_HTTP_INTERNAL_SERVER_ERROR;
>>       }
>>
>> +    r->uri = path;
>> +    ngx_http_set_exten(r);
>> +
>>       if (ngx_http_set_content_type(r) != NGX_OK) {
>>           return NGX_HTTP_INTERNAL_SERVER_ERROR;
>>       }
>
> The patch is completely incorrect.  While it might work for you in
> this particular case, it
>
> a) Breaks the behaviour which is expected to work (in contrast to
> the above), e.g. like this:
>
>      location = /foo.js {
>          alias /path/to/a/file;
>      }
>
> b) Breaks unrelated things like the $uri variable.
>
>