On 2022-03-07 at 03:37:23, 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. 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
Attachment:
signature.asc
Description: PGP signature
