Re: (Re: gitweb not friendly to firefox?) and unusable in the lynx
Show 10 quoted lines
> 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:
Show 12 quoted lines
> 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
