Nicolas Pitre wrote: > On Sat, 3 Mar 2007, Jakub Narebski wrote: > >> Could you check if "application/xhtml+xml" is in "Accept:" >> HTTP Request Header sent by _your_ lynx, e.g. as seen via >> http://web-sniffer.net/?url=http://www.kernel.org/git > > Accept: text/html, text/plain, application/pdf, application/msword, > audio/mod, image/*, application/postscript, text/sgml, */*;q=0.01 > [CRLF] > User-Agent: Lynx/2.8.5rel.1 libwww-FM/2.14 SSL-MM/1.4.1 OpenSSL/0.9.8b I'm adding back everybody which participated in this thread... There are two complications: first, sometimes http://www.kernel.org/git works with lynx (and links2, and w3m), and sometimes do not. I have reported lynx working with it, but when I tried to repeat this I got not understood (by lynx) "application/xhtml+xml" instead of correct "text/html". Second, the code responsible for setting correct content type is: my $content_type; # 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 # support xhtml+xml but choking when it gets what it asked for. if (defined $cgi->http('HTTP_ACCEPT') && $cgi->http('HTTP_ACCEPT') =~ m/(,|;|\s|^)application\/xhtml\+xml(,|;|\s|$)/ && $cgi->Accept('application/xhtml+xml') != 0) { $content_type = 'application/xhtml+xml'; } else { $content_type = 'text/html'; } As you can see lynx _does not_ include 'application/xhtml+xml' among accepted content types, and gitweb requires to have it set explicitely (i.e. having */* is not enough). BUT I have an idea: this might be caused by the gitweb _used by kernel.org_. http://www.kernel.org/git says that it use "git web interface version 1.4.5-rc0.GIT" while using "git core binaries version 1.5.0.1" which is a bit suspicious... and right so, because IIRC kernel.org uses caching version of gitweb by John 'Warthog9' http://www.kernel.org/git/?p=git/warthog9/gitweb.git;a=summary (I think it should use different identification, perhaps "caching git web interface", or "git web interface (caching)"). I guess that it caches too aggresively, caching also HTTP response (including content type). That of course might not be true, but check if for example http://repo.or.cz (which also does not run vanilla gitweb, by the way) also gives the same problems to lynx or w3m. Oleg Verych wrote: > On Sat, Mar 03, 2007 at 05:29:22AM -0800, Junio C Hamano wrote: >> >> I think the real question is if gitweb output need to be XHTML. >> If everybody's browser is happier with text/html and we do not >> have to use things only in xhtml, sending text/html out (both as >> content-type and the actual contents) feels like the right thing >> to do from compatibility point of view. > > Right XML (XHTML) isn't a tags soup as HTML is, so it's better. But > "application/xml+xml+xml" is very silly, unless site's content uses > dynamics, DOM, etc. As far as i can see, gitweb is not going to have > javascript and such yet (because of compatibility/usability). It would be nice to AJAX-ize blame view in gitweb (if it is enabled). > Thus, fixing of http content negotiation is needed, or whatever is > used in Perl for this. By the way, the change to use 'application/xhtml+xml' is by Alp Toker, made in commit f6801d669 with the following explanation: "The 'text/html' media type [RFC2854] is primarily for HTML, not for XHTML. In general, this media type is NOT suitable for XHTML." This patch makes gitweb use content negotiation to conservatively send pages as Content-Type 'application/xhtml+xml' when the user agent explicitly claims to support it. Please discuss it with Alp, if is available. -- Jakub Narebski Poland - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html