Invalid content types served when using alias

Tom van der Woerdt info at tvdw.eu
Wed Oct 24 11:52:13 UTC 2012


Yes, that's the URL I am using. Using default_type is possible but it 
still feels like a bug, especially since the actual file it's serving 
does end with .js. I know it's possible with a rewrite but that also 
feels like a hack instead of a real solution, especially since the file 
I'm serving is outside the website's root folder.

Tom


On 10/24/12 1:44 PM, Wandenberg Peixoto wrote:
> Just to be clear, are you calling "example.com/client 
> <http://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 
> <mailto: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
>>     <mailto: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 <mailto: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 <mailto:nginx-devel at nginx.org>
>>>             http://mailman.nginx.org/mailman/listinfo/nginx-devel
>>>
>>>
>>>
>>>
>>>         _______________________________________________
>>>         nginx-devel mailing list
>>>         nginx-devel at nginx.org  <mailto:nginx-devel at nginx.org>
>>>         http://mailman.nginx.org/mailman/listinfo/nginx-devel
>>
>>
>>         _______________________________________________
>>         nginx-devel mailing list
>>         nginx-devel at nginx.org <mailto:nginx-devel at nginx.org>
>>         http://mailman.nginx.org/mailman/listinfo/nginx-devel
>>
>>
>>
>>
>>     _______________________________________________
>>     nginx-devel mailing list
>>     nginx-devel at nginx.org  <mailto:nginx-devel at nginx.org>
>>     http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
>
>     _______________________________________________
>     nginx-devel mailing list
>     nginx-devel at nginx.org <mailto:nginx-devel at nginx.org>
>     http://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/97be98dd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3729 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20121024/97be98dd/attachment-0001.bin>


More information about the nginx-devel mailing list