Daniel Aleksandersen wrote:
On 2008-03-11, William A. Rowe, Jr. wrote:See the httpd 2.2 conf/extra/httpd-manual.conf for how this is rewritten to be in a specific language-space. (en/index.html vs no/index.html)So what is really the best practise? I thought of content negotiation as trying to always serve the most appropriate version for all URIs, if not especially told otherwise (by a direct link or cookie override). Should I only use language focused content negotiation on the welcome page/the index?
As best practice - the manual will serve index.html as either English or
Norwegian based on negotiation. But that wasn't your question...
The remapping to permit a en/index.html resource is an added bonus only
to allow a user to declare a particular language when their browser is
misconfigured or they perhaps want to review a specific translation.
... since the name index.html{.extension} is not variant, as your original
question was worded, this isn't a complete solution.
>> Now, if you want 12 different 'file names' for the same document, they
>> really can't be negotiated using conventional accept semantics because
>> foo.html(.en) ~= foo.html(.no) while foo.html(.en) is entirely
>> unrelated (in a uri-sense) to bar.html(.no).
>>
>> You can do it - I suggest rewrite map db's, but you'll be at this a
>> while, and likely create yourself a maintenance headache.
I'd do an absolute internal rewriting of /fiske/ -> /fishing/ - but as an
internal rewrite - it is never to be seen by the user, you are still going
to serve the files from the fishing/ subdirectory.
Then add a *conditional*, *external* rewrite of fishing/ -> fiske/ where
the preferred language is nb[-*]. But that isn't enough, their accept-
language header may have multiple values with different Q-values. At that
point perhaps a custom module is required - it's a non-trivial problem.
Bill
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|