Invalid content types served when using alias

[Wandenberg Peixoto]

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<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/119d528d/attachment.html>