Invalid content types served when using alias

[Wandenberg Peixoto]

Just to be clear, are you calling "example.com/client" and serving a js
file?
If yes, this is the problem, the mime types works based on requested
filename extension, if I am not wrong.
As you called /client the nginx don't know what mime type to deliver.
So, or you have too use the default_type on that location, or change the
request to something like /client.js,
or do a rewrite from /client to the js insted of use a location to that.

On Wed, Oct 24, 2012 at 8:05 AM, Tom van der Woerdt <info at tvdw.eu> wrote:

>  Yes, this is in my nginx.conf file :
>
> http {
>         include mime.types;
>         default_type application/octet-stream;
>
>         {more}
>
>         include /etc/nginx/conf.d/*.conf;
> }
>
> Tom
>
>
> Op 10/24/12 12:00 PM, Wandenberg Peixoto schreef:
>
> Are you using a mime.types file? Or setting types block?
> This file has a mapping from file extension to the content type, may be
> what is missing on your configuration.
>
> On Wed, Oct 24, 2012 at 6:59 AM, Tom van der Woerdt <info at tvdw.eu> wrote:
>
>>  Thanks, that works, but it doesn't really sound like a solution, more
>> like a workaround.
>>
>> Tom
>>
>>
>> Op 10/24/12 5:04 AM, Wandenberg Peixoto schreef:
>>
>> Try to set
>>
>> default_type    text/javascript;
>>
>> instead of add_header.
>>
>> Regards,
>> Wandenberg
>>
>> On Tue, Oct 23, 2012 at 9:50 PM, Tom van der Woerdt <info at tvdw.eu> 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. I tried to solve this with :
>>>
>>>         add_header Content-Type text/javascript;
>>>
>>> Now I get two Content-Type headers.
>>>
>>> The raw response:
>>>
>>> < HTTP/1.1 200 OK
>>> < Server: nginx/1.3.6
>>> < Date: Tue, 23 Oct 2012 23:42:27 GMT
>>> < Content-Type: application/octet-stream
>>> < Content-Length: 23245
>>> < Last-Modified: Sat, 20 Oct 2012 00:09:12 GMT
>>> < Connection: keep-alive
>>> < ETag: "5081eba8-5acd"
>>> < Expires: Thu, 01 Jan 1970 00:00:01 GMT
>>> < Cache-Control: no-cache
>>> < Content-Type: text/javascript
>>> < Accept-Ranges: bytes
>>>
>>> nginx information :
>>>
>>> nginx version: nginx/1.3.6
>>> built by gcc 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC)
>>> TLS SNI support enabled
>>> configure arguments: --user=nginx --group=nginx --with-http_ssl_module
>>> --with-http_gzip_static_module --with-http_secure_link_module
>>> --with-http_realip_module --with-http_stub_status_module --with-ipv6
>>> --with-openssl=/root/libraries/openssl-1.0.1c/ --prefix=/etc/nginx/
>>> --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf
>>> --error-log-path=/var/log/nginx/error.log
>>> --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid
>>> --lock-path=/var/run/nginx.lock
>>> --http-client-body-temp-path=/var/cache/nginx/client_temp
>>> --http-proxy-temp-path=/var/cache/nginx/proxy_temp
>>> --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp
>>> --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp
>>> --http-scgi-temp-path=/var/cache/nginx/scgi_temp
>>>
>>> Server information :
>>>
>>> Linux hostname.goes.here 2.6.32-279.5.2.el6.centos.plus.i686 #1 SMP Thu
>>> Aug 23 22:13:33 UTC 2012 i686 i686 i386 GNU/Linux
>>>
>>> It's not a major issue for me (browsers will accept octet-stream just
>>> fine) but might be annoying for other people, should they ever run into
>>> this.
>>>
>>> Tom
>>>
>>> _______________________________________________
>>> nginx-devel mailing list
>>> nginx-devel at nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>>>
>>
>>
>>
>> _______________________________________________
>> nginx-devel mailing listnginx-devel at nginx.orghttp://mailman.nginx.org/mailman/listinfo/nginx-devel
>>
>>
>>
>> _______________________________________________
>> nginx-devel mailing list
>> nginx-devel at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>>
>
>
>
> _______________________________________________
> nginx-devel mailing listnginx-devel at nginx.orghttp://mailman.nginx.org/mailman/listinfo/nginx-devel
>
>
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20121024/5457c2ad/attachment.html>