Howto force text type of dir/subdir/file?

Server NGINX
1

Hi,

On a CentOS 6.4 box with nginx 1.4.1 I would like to expose
/usr/share/doc/* as /doc so I can easily browse the docs from
the installed packages.

Config I have right now (thanks Nodex on irc for pointing me to types):

docs

location /doc {
alias /usr/share/doc/;
autoindex on;
types { }
default_type text/plain;
}

This works fine when I browse to for example:
https:///doc/procmail-3.22/examples/1procmailrc

But it does not work for:

https:///doc/postfix-2.6.6/README_FILES/AAAREADME

Not work meaning Firefox offers the AAAREADME file for download.

file AAAREADME

AAAREADME: ASCII text, with overstriking

Anyone have a hint what I am doing wrong?

Thanks!
Patrick

2

— Original message —
From: “Patrick L.” [email protected]
Date: 29 May 2013, 17:35:18

alias /usr/share/doc/;
autoindex on;
types { }
default_type text/plain;
}

What is in log?

Also, from nginx docs:

When location matches the last part of the directive’s value:

location /images/ {
    alias /data/w3/images/;
}

it is better to use the root directive instead:

location /images/ {
    root /data/w3;
}
3

On 05/29/2013 06:11 PM, wishmaster wrote:
[snip]

What is in log?

In the access.log:

Working ok when browsing a procmail file:

<my_ip> - - [29/May/2013:18:15:15 +0200] “GET
/doc/procmail-3.22/examples/ HTTP/1.1” 200 1597
“https:///doc/procmail-3.22/” “Mozilla/5.0 (X11; Linux x86_64;
rv:21.0) Gecko/20100101 Firefox/21.0”

Not working when browsing a Postfix file:

<my_ip> - - [29/May/2013:18:17:00 +0200] “GET
/doc/postfix-2.6.6/README_FILES/INSTALL HTTP/1.1” 200 33503
“https:///doc/postfix-2.6.6/README_FILES/” “Mozilla/5.0 (X11;
Linux x86_64; rv:21.0) Gecko/20100101 Firefox/21.0”

There is nothing in the error log.

 location /images/ {
     root /data/w3;
 }

Thanks for the tip. Changed my config to:

docs

location /doc/ {
#alias /usr/share/doc/;
root /usr/share;
autoindex on;
types { }
default_type text/plain;
}

I still have the same issue in the postfix subdir though.

Regards,
Patrick

4

Hi Francis,

On 05/30/2013 12:37 AM, Francis D. wrote:

On Wed, May 29, 2013 at 04:35:03PM +0200, Patrick L. wrote:

Hi there,
[snip]

What does

curl -I https:///doc/postfix-2.6.6/README_FILES/AAAREADME

show as the Content-Type?

If it is “text/plain”, your nginx is doing what you told it to do.

Yup seems so:

HTTP/1.1 200 OK
Server: nginx
Date: Thu, 30 May 2013 00:23:22 GMT
Content-Type: text/plain
Content-Length: 2768
Last-Modified: Sat, 03 Dec 2011 05:00:55 GMT
Connection: keep-alive
Keep-Alive: timeout=10
ETag: “4ed9ad07-ad0”
X-Frame-Options: SAMEORIGIN
Accept-Ranges: bytes

identifies in that same way. The Content-Type: header is text/plain.
instead of the single X. So remove the ^H and one X each time, and you
should have a real text/plain file.

And perhaps invite whoever put the file there to only use plain text in
the next version of the package.

Understand now, thanks. To me it was just a text file like the other
real ones. It’s the postfix documentation that has the overstrike
thingy. I doubt Wietse is going to change that anytime soon. No biggie
though. The postfix website has all the docs too.

Cheers,
Patrick

5

On Wed, May 29, 2013 at 04:35:03PM +0200, Patrick L. wrote:

Hi there,

This works fine when I browse to for example:
https:///doc/procmail-3.22/examples/1procmailrc

But it does not work for:

https:///doc/postfix-2.6.6/README_FILES/AAAREADME

Not work meaning Firefox offers the AAAREADME file for download.

What does

curl -I https:///doc/postfix-2.6.6/README_FILES/AAAREADME

show as the Content-Type?

If it is “text/plain”, your nginx is doing what you told it to do.

Strictly, I suspect that the file is not text/plain, since the control
characters are not normally printable.

So Firefox is probably right to indicate that it is unable to present
the file contents correctly, since they do not match the declared type.

file AAAREADME

AAAREADME: ASCII text, with overstriking

I’ve just tested on a different server, using a file which “file”
identifies in that same way. The Content-Type: header is text/plain.

Anyone have a hint what I am doing wrong?

My guess is: claiming that a non-text/plain file is text/plain. nginx
doesn’t care; it just does what it is told. Firefox does care.

The simplest thing is probably for you to edit the file to make it be
text/plain. And do the same for any other similar file.

“overstriking” is usually having the three character sequence X ^H X
instead of the single X. So remove the ^H and one X each time, and you
should have a real text/plain file.

And perhaps invite whoever put the file there to only use plain text in
the next version of the package.

f

Francis D. [email protected]