If a URL is submitted without a language extension
(e.g. *.jsp instead of *.en), and the client
(user-agent) doesn't supply any language preferences in
the request, a 404 error is returned (unless the
content item is being cached by the server).
This has implications for our site(s), where the *.jsp
extension has been carried over (in content) as part of
a recent migration. If we use a link checker which
doesn't specify a language extension we get a number of
'false' broken links.
This patch takes the existing languages configuration
parameter (com.arsdigita.cms.languages), and uses it as
the basis for server language preferences. Thus if no
suitable language match is found in the URL extension
or client request, then the server preferences are
considered.
The supplied patch file is made against the 1.0.2
release (r982).
Alun
Note: There is still a related issue outstanding, in
that it appears that no language negotiation takes
place if a content item is cached by the server. In
this case, presumably, whichever language item is held
- is served up without negotiation.