From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: Jason Yundt <jason@jasonyundt.email>,
git@vger.kernel.org, Jeff King <peff@peff.net>
Subject: Re: [PATCH v2 2/2] gitweb: remove invalid http-equiv="content-type"
Date: Tue, 08 Mar 2022 13:44:35 +0100 [thread overview]
Message-ID: <220308.86cziwy595.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <Yia2Y2zoOjvVdJ9O@camp.crustytoothpaste.net>
On Tue, Mar 08 2022, brian m. carlson wrote:
> [[PGP Signed Part:Undecided]]
> On 2022-03-08 at 01:07:11, Jason Yundt wrote:
>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>> index fbd1c20a23..59457c1004 100755
>> --- a/gitweb/gitweb.perl
>> +++ b/gitweb/gitweb.perl
>> @@ -4225,7 +4225,7 @@ sub git_header_html {
>> <!-- git web interface version $version, (C) 2005-2006, Kay Sievers <kay.sievers\@vrfy.org>, Christian Gierke -->
>> <!-- git core binaries version $git_version -->
>> <head>
>> -<meta http-equiv="content-type" content="$content_type; charset=utf-8"/>
>> +<meta charset="utf-8"/>
>
> I don't actually think this is an improvement. I don't think it's
> necessary, considering we have an XML declaration and the HTTP header,
> both of which already say it's UTF-8 and will take precedence over this.
Ageed. I was a bit surprised per Jason's
https://lore.kernel.org/git/109813056.nniJfEyVGO@jason-desktop-linux/
that the removal wasn't kept.
I.e. he was replying to a question of mine asking whether we didn't need
this data at rest, e.g if you save the page. I didn't notice the "<?xml
version..." we emit, which seems to be enough.
I.e. this seems to have always been redundant going back to c994d620cc8
(v220, 2005-08-07), or rather, the character set part of it.
Maybe I still don't understand this, but the commit message seems to me
be conflating whether we send the *right* http-equiv with whether we
send it at all, i.e. if the problem is that XML documents shouldn't be
text/html isn't this correct?:
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index fbd1c20a232..c1c5af0b197 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4049,7 +4049,13 @@ sub get_page_title {
return $title;
}
+sub get_content_type_xml {
+ return 'application/xhtml+xml';
+}
+
sub get_content_type_html {
+ my ($want_xml) = @_;
+
# require explicit support from the UA if we are to send the page as
# 'application/xhtml+xml', otherwise send it as plain old 'text/html'.
# we have to do this because MSIE sometimes globs '*/*', pretending to
@@ -4057,7 +4063,7 @@ sub get_content_type_html {
if (defined $cgi->http('HTTP_ACCEPT') &&
$cgi->http('HTTP_ACCEPT') =~ m/(,|;|\s|^)application\/xhtml\+xml(,|;|\s|$)/ &&
$cgi->Accept('application/xhtml+xml') != 0) {
- return 'application/xhtml+xml';
+ return get_content_type_html();
} else {
return 'text/html';
}
@@ -4214,6 +4220,7 @@ sub git_header_html {
my $title = get_page_title();
my $content_type = get_content_type_html();
+ my $content_type_xml = get_content_type_html();
print $cgi->header(-type=>$content_type, -charset => 'utf-8',
-status=> $status, -expires => $expires)
unless ($opts{'-no_http_header'});
@@ -4225,7 +4232,7 @@ sub git_header_html {
<!-- git web interface version $version, (C) 2005-2006, Kay Sievers <kay.sievers\@vrfy.org>, Christian Gierke -->
<!-- git core binaries version $git_version -->
<head>
-<meta http-equiv="content-type" content="$content_type; charset=utf-8"/>
+<meta http-equiv="content-type" content="$content_type_xml; charset=utf-8"/>
<meta name="generator" content="gitweb/$version git/$git_version$mod_perl_version"/>
<meta name="robots" content="index, nofollow"/>
<title>$title</title>
Of course we might then *also* decide that <meta http-equiv> in this
case isn't needed at all, but isn't that a seperate change?
And won't conforming browsers treat application/xhtml+xml differently
when the page is saved? A long time ago (Idid some web development)
using it would enable pedantic strictness in browsers, i.e. unclosed
tags etc. would be a hard error, but I can't reproduce that locally in
either Firefox or Chrome now (with just the gitweb output as-is with
that http-equiv tweaked).
So maybe it does nothing, or maybe it's just those browser...
next prev parent reply other threads:[~2022-03-08 12:54 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-07 3:37 [PATCH 0/2] gitweb: remove invalid http-equiv="content-type" Jason Yundt
2022-03-07 3:37 ` [PATCH 1/2] comment: fix typo Jason Yundt
2022-03-07 3:37 ` [PATCH 2/2] gitweb: remove invalid http-equiv="content-type" Jason Yundt
2022-03-07 12:23 ` Ævar Arnfjörð Bjarmason
2022-03-07 22:49 ` Jason Yundt
2022-03-07 23:24 ` brian m. carlson
2022-03-08 1:07 ` [PATCH v2 0/2] " Jason Yundt
2022-03-08 2:13 ` Junio C Hamano
2022-03-08 12:26 ` Jason Yundt
2022-03-08 15:56 ` [PATCH v3 " Jason Yundt
2022-03-08 15:56 ` [PATCH v3 1/2] comment: fix typo Jason Yundt
2022-03-08 15:56 ` [PATCH v3 2/2] gitweb: remove invalid http-equiv="content-type" Jason Yundt
2022-03-08 1:07 ` [PATCH v2 1/2] comment: fix typo Jason Yundt
2022-03-08 1:07 ` [PATCH v2 2/2] gitweb: remove invalid http-equiv="content-type" Jason Yundt
2022-03-08 1:50 ` brian m. carlson
2022-03-08 12:44 ` Ævar Arnfjörð Bjarmason [this message]
2022-03-08 14:54 ` Jason Yundt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=220308.86cziwy595.gmgdl@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=jason@jasonyundt.email \
--cc=peff@peff.net \
--cc=sandals@crustytoothpaste.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.