I have all my personal web pages ending in the their ISO language code
as extension, so the Apache server chooses the appropriate one
according to the Accepted-Language HTTP header from the browser. This
means all my files are named like

foo.xhtml.en
foo.xhtml.es

This is necessary in my case, and common practice. ELinks chokes at
this, though, because it relies on extension rather than content for
identifying HTML and the extension isn't .xhtml nor .html. The
consequence is they aren't recognized as HTML, but as
application/something, forcing you to open the file as binary and parse
it afterwards as HTML with ^\.

As soon as I link any of these files to .xhtml extension and open them
from that name they are recognized immediately. It's the same
with .html.

I think there are two possible solutions to this:

1. Adapting to Apache's naming convention and so recognizing all ISO
   language codes as extension.

2. Relying on content instead of extension, which means just making
   Elusive try to parse the file, and is, IMHO, the correct solution.

I tested the version in experimental using the attached file, and it
worked correctly.

reopen 1036444
severity 1036444 grave
tags 1036445 patch
thanks

Please, don't close bug reports until you are sure the bug is fixed.

This file is not conforming XHTML 1. It's just HTML. As I explained you
in #1036382, XHTML 1 is a subset of HTML 4 that is also XML conformant.
So there are additional elements to add in this file, namely the
opening XML version line, the XHTML 1 DOCTYPE, the xmlns and xml:lang
attributes to the html tag, and closing tags for the paragraphs, since
it's mandatory to close all tags.

You have the simplest you example of a valid XHTML 1.1 document you can
find on the hello-world.xhtml file I attached you on #1036382, in case
you want to see a whole and save it for testing.

Please, don't close bugs that you think are fixed on experimental until
the fix is already on all supported releases containing the bug and you
are sure the bug is fixed.

In this case your test file wasn't conforming XHTML 1.1, as I
explained, so it's not good to reproduce it.

No, I have no box available with experimental at this time, sorry.

But it makes little difference. The bug was filed for version
0.13.2-1+b1 so it's in all supported releases this version exists where
you have to test it, besides sid.

Please, also note experimental is not the right release for development
usually, that would be sid (unstable).

Patch tag does not mean necessarily that a patch is attached. A simple
description for fixing it is enough:

   patch
          A patch or some other easy procedure for fixing the bug is
          included in the bug logs. [...]

In this case my procedure was at the bottom of my report. It should be
easy enough for the developers.

As in #1036382, all you have to do is confirm you can reproduce it with
the same package version, confirm the bug is not caused by a Debian
patch, and forward the report to upstream. Also try to reproduce
through network, if you can.

I wonder why you think severity is normal or important, and more so why
you don't even seem to know which of these is supposedly. Quoting the
severity's description doesn't provide your reason :)

My reasoning is analogue to the one I had for #1036382 initially, which
is provided there and in this report.

Considering you are maintaining a web browser you should be able to
make up an elementary XHTML 1.1 test file yourself. Anyway, as I said,
I provided one also to you in #1036382, named hello-world.xhtml. Just
rename to

  hello-world.xhtml.en

Thanks a lot for this, and sorry for the last control message mess.

It would have been more useful if you pointed to the bug report, as
well as making a brief summary as you did. Just the URL would have been
enough.

Regards,
JL