Invalid content types served when using alias

[Vladimir Shebordaev]

Hi!

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.

I daresay that is also why your message does not make much sense :)

>
> 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).
>

It is the case when the MIME type can not be guessed from URI but 
can be inferred from the file redirect extension.

>>
>> 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;
>      }

Sure, it should be done in more elaborate way, like by, e.g 
try_files handler. At least, it should be only done if r->exten 
has not been guessed from the original URI. I would also do that 
if I expect the patch to be applied as-is.

>
> b) Breaks unrelated things like the $uri variable.
>
>

Well, as long as the Content-Length is already set to the length 
of the file I didn't expect variables to be evaluated, but, sure, 
there is log module and probably others.

Thank you, but I guess no fixes are to be applied anyways.

Regards,
Vladimir