Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm attempting to get the MultiViews option working in Apache to vary the content returned to the browser based on the Accept-Language provided in requests.

I've got the following configuration:

Alias /multiviewstest "C:/MultiViews Test"

<Directory "C:/MultiViews Test">
    Options MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

In my C:\MultiViews Test directory I have the following files:

  • spam.html
  • foo.html.en

When I request http://localhost/multiviewstest/spam the contents of spam.html is returned. Here are the request and response headers:

Host: localhost
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

Date: Fri, 08 May 2009 11:07:54 GMT
Server: Apache/2.2.10 (Win32)
Content-Location: spam.html
Vary: negotiate
TCN: choice
Last-Modified: Fri, 08 May 2009 10:48:34 GMT
Etag: "0-4-469645ec81e70;469645ff5a5d8"
Accept-Ranges: bytes
Content-Length: 4
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html

The Content-Location, Vary, and TCN response headers indicates MultiViews have correctly kicked in.

I've configured English as the only preferred language for displaying languages in my browser; an Accept-Language en header is set on requests. When I request http://localhost/multiviewstest/foo.html a 404 response is returned. Based on my understanding of Apache's file naming conventions for language negotiation I'd expect the contents of the foo.html.en file to be returned.

Here are the request and response headers:

Host: localhost
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

Date: Fri, 08 May 2009 11:08:39 GMT
Server: Apache/2.2.10 (Win32)
Content-Length: 221
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

Here's what appears in the access log for the request:

127.0.0.1 - - [04/May/2009:10:28:24 +1200] "GET /multiviewstest/foo.html HTTP/1.1" 404 221

And from the error log:

[Mon May 04 10:28:24 2009] [error] [client 127.0.0.1] Negotiation: discovered file(s) matching request: C:/MultiViews Test/foo.html (None could be negotiated).

Why isn't the content negotiation for the language correctly kicking in? Is there some configuration I have overlooked?

share|improve this question
    
Have you looked at both your error and access logs? –  Vinko Vrsalovic May 2 '09 at 11:27
    
I've added the appropriate entries from the logs to the post. –  Simon Lieschke May 3 '09 at 22:40
    
Can you post both the request and response headers of the successful (spam) and unsuccessful (foo) requests? –  jj33 May 7 '09 at 1:49
    
Done; I've added the headers for both the requests into the question. –  Simon Lieschke May 8 '09 at 11:17

3 Answers 3

up vote 2 down vote accepted

Do the proper language/extension relationships exist in your configuration?

AddLanguage en .en
LanguagePriority en fr de
ForceLanguagePriority Fallback
share|improve this answer
    
Bingo! An AddLanguage directive was enough to fix the problem, but I'll check out the other directives too. It would have been helpful if the Apache content negotation documentation I linked mentioned something about the AddLanguage directive. Nonetheless, thanks! –  Simon Lieschke May 14 '09 at 3:26

FWIW, I ran into a similar issue, with the proper AddLanguage etc directives in place. Eventually I realized that the problem was PHP-specific.

For some reason I was using SetHandler within a FilesMatch directive:

<FilesMatch \.php$>
    SetHandler application/x-httpd-php
</FilesMatch>

Switching to a simple AddType solved the problem:

AddType application/x-httpd-php .php
share|improve this answer

The answer given by metkat hinted at the source of my trouble as well. However, I decided for a different approach. This is what my config had:

<FilesMatch ".+\.ph(p[345]?|t|tml)$">
    SetHandler application/x-httpd-php
</FilesMatch>

And this is what I changed it into:

<FilesMatch ".+\.ph(p[345]?|t|tml)(\.[a-z]{2}|)$">
    SetHandler application/x-httpd-php
</FilesMatch>

I basically added to the end of the file name: (\.[a-z]{2}|), which means "...followed by a dot and two characters of the range a-z OR (|) nothing". Seems to work smoothly so far :)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.