Project

General

Profile

Feature #2767

Render dirlisting as HTML

Added by altblue 7 months ago. Updated 5 months ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
mod_dirlisting
Target version:
Start date:
2016-11-09
Due date:
% Done:

100%

Missing in 1.5.x:

Description

Currently mod_dirlisting pretends to create XHTML, but output is served as "text/html" => dir-listing.external-js becomes useless, as it's inserted as self-closing element, which is interpreted as "tag-soup".

Attached patch turns all XHTML into plain HTML and some tiny extras:
- add "charset" meta tag (in order to make saved renderings consistent when used locally);
- (if "external_css" is used, then) insert a minimal "viewport" meta tag (in order to make pages more usable on mobile devices);
- insert "script" after "div.foot" (ok, that's still inside the "body", but at least now it's the last child… maybe setting "async" would be even better);

Ref:
http://stackoverflow.com/questions/69913/why-dont-self-closing-script-tags-work
http://stackoverflow.com/questions/97522/what-are-all-the-valid-self-closing-elements-in-xhtml-as-implemented-by-the-maj

lighttpd-1.4.43-mod_dirlisting-html.patch View (3.48 KB) altblue, 2016-11-09 03:17

lighttpd-1.4.43-mod_dirlisting-html.patch View (3.34 KB) gstrauss, 2016-12-02 05:16

Associated revisions

Revision 090985af (diff)
Added by gstrauss 6 months ago

[mod_dirlisting] render dirlisting as HTML (fixes #2767)

(thx altblue)

x-ref:
"Render dirlisting as HTML"
https://redmine.lighttpd.net/issues/2767

History

#1 Updated by gstrauss 6 months ago

Thanks! I will try to review this in the next week or so, after the Thanksgiving holiday in the U.S.

#2 Updated by gstrauss 6 months ago

The tiny extras all seem like good ideas.

I have some questions about the rest of the patch:

Currently mod_dirlisting pretends to create XHTML, but output is served as "text/html" => dir-listing.external-js becomes useless, as it's inserted as self-closing element, which is interpreted as "tag-soup".

So, would it be better if mod_dirlisting set HTTP response header Content-Type: text/xml; charset=... instead of text/html?

Any deleterious affects from the following behavior changes?

dir-listing.auto-layout is enabled by default. With your patch (and dir-listing.auto-layout enabled), the specification that the generated page is xml:lang="en" has been removed. Also removed is the specification that the generated page has charset=iso-8859-1 if dir-listing.encoding has not been set. That last one is easy to add back.

With your patch, note that if dir-listing.auto-layout is disabled but dir-listing.encoding is set, then the encoding is no longer part of the body output after your patch is applied. (The encoding is still part of the HTTP response header.)

Would sending Content-Type: text/xml be a better choice?

#3 Updated by altblue 6 months ago

gstrauss wrote:

would it be better if mod_dirlisting set HTTP response header Content-Type: text/xml; charset=... instead of text/html?

I guess you mean application/xhtml+xml (with text/xml you will need to explain browsers how you want the output to be rendered – e.g. XSL): you would be complicating things by enforcing publishers to develop "XML apps".
Going the HTML way is far easier for (virtually) everyone.

dir-listing.auto-layout is enabled by default. With your patch (and dir-listing.auto-layout enabled), the specification that the generated page is xml:lang="en" has been removed.

This is not relevant when talking about HTML (i.e. not XHTML).

Also removed is the specification that the generated page has charset=iso-8859-1 if dir-listing.encoding has not been set.

That already is the creepy default, you don't have to add anything. ;-)

if dir-listing.auto-layout is disabled but dir-listing.encoding is set, then the encoding is no longer part of the body output after your patch is applied. (The encoding is still part of the HTTP response header.)

Nowadays publishers are able to override HTTP Content-Type (i.e. through BOM or META in the first 1KB), so, as long as they do properly use it to markup their "non-auto-layout" heading, everything should work as expected, both "online" (when served through HTTP) and "offline" (when rendering saved docs locally).

#4 Updated by gstrauss 6 months ago

Also removed is the specification that the generated page has charset=iso-8859-1 if dir-listing.encoding has not been set.

That already is the creepy default, you don't have to add anything. ;-)

FYI: This is no longer the default behavior.
https://tools.ietf.org/html/rfc7231

Appendix B.  Changes from RFC 2616
[...]
   The default charset of ISO-8859-1 for text media types has been
   removed; the default is now whatever the media type definition says.
   Likewise, special treatment of ISO-8859-1 has been removed from the
   Accept-Charset header field.  (Section 3.1.1.3 and Section 5.3.3)

I would prefer to maintain as close to current behavior as possible (if correct) and to explicitly specify iso-8859-1 unless there is a compelling reason to change this behavior.

#5 Updated by gstrauss 6 months ago

updated patch, but chose not to add iso-8859-1 to meta charset since current behavior does not include it in Content-Type header, unless dir-listing.encoding is set. Please see if this is acceptable to you.

#6 Updated by gstrauss 6 months ago

  • Status changed from Patch Pending to Need Feedback

#7 Updated by gstrauss 5 months ago

  • Status changed from Need Feedback to Fixed
  • % Done changed from 0 to 100

Also available in: Atom