Bug#1036444: closed by أحمد المحمودي (Re: Bug#1036444: elinks: relies on file extension for files instead of content)

2023-05-20 Thread José Luis González
reopen 1036444
severity 1036444 grave
tags 1036445 patch
thanks

> #1036444: elinks: relies on file extension for files instead of content
> 
> It has been closed by أحمد المحمودي .

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

> 
> 
>  para1
>  para2
> 
> 

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.

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

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.

> > Version: 0.13.2-1+b1
> 
> Could you test the version in experimental (0.16.1.1) /?

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).

> > Tags: upstream, patch
> 
> No patch attaxhed, removing patch tag.

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.

> > Severity: grave
> Quoting https://www.debian.org/Bugs/Developer :
> "
> grave
>  makes the package in question unusable or mostly so, or causes data 
>   loss, or introduces a security hole allowing access to the accounts of 
>   users who use the package.
> "
>
> hence severity is either normal or important.

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.

> > ELinks is not recognizing MIME type text/xml+xhtml nor text/xml, which
> > are the recommended types for XHTML, on added file extensions. This
> > means that, despite XHTML 1.0 and XHTML 1.1 documents are valid HTML 4
> > they are not recognized unless you use text/html type.
>
> Please attach a file that I can use to test the issue.

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



Bug#1036444: elinks: relies on file extension for files instead of content

2023-05-20 Thread José Luis González
Package: elinks
Version: 0.13.2-1+b1
Severity: important

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.