git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Jason Yundt <jason@jasonyundt.email>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>
Subject: Re: [PATCH 2/2] gitweb: remove invalid http-equiv="content-type"
Date: Mon, 07 Mar 2022 13:23:49 +0100	[thread overview]
Message-ID: <220307.861qze0wv9.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <20220307033723.175553-3-jason@jasonyundt.email>


On Sun, Mar 06 2022, Jason Yundt wrote:

> Before this change, gitweb would generate pages which included:
>
> 	<meta http-equiv="content-type" content="application/xhtml+xml; charset=utf-8"/>
>
> A meta element with http-equiv="content-type" is said to be in the
> "Encoding declaration state". According to the HTML Standard,
>
> 	The Encoding declaration state may be used in HTML documents,
> 	but elements with an http-equiv attribute in that state must not
> 	be used in XML documents.
>
> 	Source: <https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv-content-type>
>
> This change removes that meta element since gitweb always generates XML
> documents.
>
> Signed-off-by: Jason Yundt <jason@jasonyundt.email>
> ---
>  gitweb/gitweb.perl                        |  4 +---
>  t/t9502-gitweb-standalone-parse-output.sh | 13 +++++++++++++
>  2 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index fbd1c20a23..606b50104c 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -4213,8 +4213,7 @@ sub git_header_html {
>  	my %opts = @_;
>  
>  	my $title = get_page_title();
> -	my $content_type = get_content_type_html();
> -	print $cgi->header(-type=>$content_type, -charset => 'utf-8',
> +	print $cgi->header(-type=>get_content_type_html(), -charset => 'utf-8',

I think it would be better to just skip this hunk, no behavior will
change if it's left in.

>  	                   -status=> $status, -expires => $expires)
>  		unless ($opts{'-no_http_header'});
>  	my $mod_perl_version = $ENV{'MOD_PERL'} ? " $ENV{'MOD_PERL'}" : '';
> @@ -4225,7 +4224,6 @@ 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"/>

..with this being the only behavior change (yeah the variable will now
be used only in one place, but that's fine)

I'm not sure I understand this change really. The result in always XML,
so application/xhtml+xml is redundant, text/html, or both?

But aside from that: I have seen browsers get the lack of encoding=""
"wrong" with data at rest, don't some still default to ISO-8859-1?

So won't this result in badly decoded data if you save the web page &
view it locally?

>  <meta name="generator" content="gitweb/$version git/$git_version$mod_perl_version"/>
>  <meta name="robots" content="index, nofollow"/>
>  <title>$title</title>
> diff --git a/t/t9502-gitweb-standalone-parse-output.sh b/t/t9502-gitweb-standalone-parse-output.sh
> index e7363511dd..25165edacc 100755
> --- a/t/t9502-gitweb-standalone-parse-output.sh
> +++ b/t/t9502-gitweb-standalone-parse-output.sh
> @@ -207,4 +207,17 @@ test_expect_success 'xss checks' '
>  	xss "" "$TAG+"
>  '
>  
> +no_http_equiv_content_type() {
> +	gitweb_run "$@" &&
> +	! grep -Ei "http-equiv=['\"]?content-type" gitweb.body

Nit: Should we skip the "-i" here since we're testing our own output,
and not http standards in general (i.e. we don't have to worry about the
case of http-equiv?)

  reply	other threads:[~2022-03-07 12:29 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 [this message]
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
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=220307.861qze0wv9.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jason@jasonyundt.email \
    --cc=peff@peff.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).