Multilingual ErrorDocuments vs. content-type negotiation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I'm having an annoying problem as a result of enabling multilingual error documents. The situation is this:

  - I'm using the multilingual error docs that come with apache 2.4.x.
  - I have clients other than web browsers --- API consumers, WebDAV clients, etc. --- which don't include text/html in their Accept: headers.

When an error of some kind occurs, Apache goes and looks through the typemap for a matching error page. Unfortunately it doesn't find one, since all of the error pages are HTML. So instead, it returns a generic error page (in HTML!), as well as logging an "AH00690: no acceptable variant" message, changing the response code in the CombinedLog to 406, and generally emitting noise.

If there *isn't* a typemap for multilingual error docs, then Apache will happily return an HTML error page to the client, even though the client does not Accept: text/html. (I'm not sure what the standards have to say about this situation, but this seems like the generally preferable behavior for error documents, and what I would expect.)

Obviously, I can simply turn off multilingual error documents to get the behavior I want, but I'd like to keep the l10n if I can.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx






[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux