Re: [PATCH 2/2] gitweb: remove invalid http-equiv="content-type"

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Mar 7, 2022, 23:24 UTC
Message-ID: <YiaUP3b3PJWZx+AY@camp.crustytoothpaste.net>
In-Reply-To: <20220307033723.175553-3-jason@jasonyundt.email>

On 2022-03-07 at 03:37:23, Jason Yundt wrote:

Show 15 quoted lines

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

This change seems fine. We do specify this in the HTTP header, including the character set, which is what matters, so this should work in every browser, and the http-equiv is unneeded.

I also don't think we need a meta header here, since we have an XML declaration, and that's controlling in this situation. This isn't regular HTML and we don't declare it as such, so using a meta header to control this isn't correct: the XML declaration should be used instead in the event a user downloads this to a local disk and processes it outside the context of an HTTP request.

Since we control the HTTP headers, I'd actually argue that your test might well reject all http-equiv headers since they could be done much better with actual HTTP headers (and would therefore work with non-browser clients), but I don't think that's worth a reroll, nor do I think a test is even needed here (but bonus points for adding one).

So I think this looks good as is.  Thanks for the patch.

-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA