search

emikulic / darkhttpd

When you need a web server in a hurry.
https://unix4lyfe.org/darkhttpd/
ISC License
1.05k stars 87 forks source link

Non-ASCII filelist compatibility #1

Closed tieugene closed 3 years ago

tieugene commented 3 years ago

As for 1.12 the patch was:

--- darkhttpd.c.orig    2020-12-05 23:50:47.745138608 +0300
+++ darkhttpd.c 2020-12-05 23:52:36.930425427 +0300
@@ -1819,7 +1819,7 @@
     }

     listing = make_apbuf();
-    append(listing, "<html>\n<head>\n <title>");
+    append(listing, "<html>\n<head>\n<meta charset=\"UTF-8\">\n<title>");
     append(listing, conn->url);
     append(listing, "</title>\n</head>\n<body>\n<h1>");
     append(listing, conn->url);
emikulic commented 3 years ago

Would you like to turn this into a pull request or do you want me to take care of it? :)

emikulic commented 3 years ago

Is meta charset needed considering the headers have Content-Type: text/html; charset=UTF-8 ?

I tried a build without your patch and e.g. ö shows up fine in the file list.

What's the bug and how can I repro it?

tieugene commented 3 years ago

Is meta charset needed considering the headers have Content-Type: text/html; charset=UTF-8 ?

I tried a build without your patch and e.g. ö shows up fine in the file list.

What's the bug and how can I repro it?

I tried with 1.12 on CentOS7 ru_RU.UTF-8 as server side and Windows RU/Fedora ru_RU.UTF-8 as client side with Firefox and Chrome. May be you client divine encoding, or client side guess html5 (which use uft-8 by default) - I don't know. But as for standards html pages without charset can be acceptable as ISO8859-1 or something like this. '<html'> declaration is not html5 nor html 4.01 so client behaviour is unpredictable.

BTW maybe html5-like <meta charset="UTF-8"> will be better (if whole of html is html5). And/or using external template[s] for file list pages.

emikulic commented 3 years ago

I don't think I'll be able to repro that. :(

  1. How come having UTF-8 in the Content-Type header isn't enough?
  2. So you get some wrong display without the meta tag, but with your patch it works?
tieugene commented 3 years ago

I don't think I'll be able to repro that. :(

  1. How come having UTF-8 in the Content-Type header isn't enough?
  2. So you get some wrong display without the meta tag, but with your patch it works?

Let me test deeper - with fresh release, fresh installation and misc clients.

tieugene commented 3 years ago

I don't think I'll be able to repro that. :(

  1. How come having UTF-8 in the Content-Type header isn't enough?
  2. So you get some wrong display without the meta tag, but with your patch it works?

Ok, try it: http://www.doxgen.ru Problems start inside any non-ascii folder - 1-2 steps in and you don't know where you are.

emikulic commented 3 years ago

What I see with Chrome is the navigation works correctly but the title and h1 have a bunch of percent signs and hex instead of text. Is this what you see also?

tieugene commented 3 years ago

What I see with Chrome is the navigation works correctly but the title and h1 have a bunch of percent signs and hex instead of text. Is this what you see also?

Exactly. Firefox, Chromium, Falkon, Midori (Linux), Safari (macOS) - all of them show "/%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA/" instead of "/Русский_язык/"

emikulic commented 3 years ago

Fixed in https://github.com/emikulic/darkhttpd/commit/3058f910d93199102e0bd6d829e22cca86f44a39

tieugene commented 3 years ago

Works fine, thank you.