bug with gitweb on kernel.org

bug with gitweb on kernel.org

[Nicolas Pitre]

Almost 2 months ago we discussed about gitweb not properly detecting the 
client's ability to deal with application/xhtml+xml, something to do 
with the caching of a previous request from a client which did support 
it and serving the same content to a subsequent client which does not.

Right now www.kernel.org/git is unusable for me with lynx as it keeps 
prompting:

	application/xhtml+xml  D)ownload, or C)ancel

Is there any plan to have that fixed?


Nicolas

Re: bug with gitweb on kernel.org

[J.H.]

On Thu, 2007-04-19 at 23:02 -0400, Nicolas Pitre wrote:
> Almost 2 months ago we discussed about gitweb not properly detecting the 
> client's ability to deal with application/xhtml+xml, something to do 
> with the caching of a previous request from a client which did support 
> it and serving the same content to a subsequent client which does not.

I apparently missed that entire conversation, my apologies.

> 
> Right now www.kernel.org/git is unusable for me with lynx as it keeps 
> prompting:
> 
> 	application/xhtml+xml  D)ownload, or C)ancel
> 
> Is there any plan to have that fixed?
> 

Well there are a couple of quick thoughts, so far (in my quick testing)
lynx and IE are the only two browsers that have issues with this
particular bit of code.  Links, konqueror, safari, firefox, mozilla, etc
all seem to handle the pages without issue.  Taking a quick glance at
the code it seems IE claims to be xhtml+xml compliant but apparently
isn't really (any real surprise?) and lynx just doesn't seem to support
that mime type.

The simplest fix would be to eliminate the distinction between
applicatoin/xhtml+xml and application/html in the gitweb code (or at
least in the caching gitweb code) and have everything claim a mimetype
of application/html and let the browser sort out if it's using xhtml or
html from the doctype.  This would solve both the problem your seeing on
lynx and would make the caching gitweb usable by more IE users.

Some quick testing on my part seems to indicate this doesn't break
behavior for any of the clients I have access to, but I thought I'd
check and see if anyone had any concerns over this particular change
before I barrel ahead with it in the caching gitweb code.

- John 'Warthog9' Hawley

Re: bug with gitweb on kernel.org

[Nicolas Pitre]

On Sun, 22 Apr 2007, J.H. wrote:

> On Thu, 2007-04-19 at 23:02 -0400, Nicolas Pitre wrote:
> > Almost 2 months ago we discussed about gitweb not properly detecting the 
> > client's ability to deal with application/xhtml+xml, something to do 
> > with the caching of a previous request from a client which did support 
> > it and serving the same content to a subsequent client which does not.
> 
> I apparently missed that entire conversation, my apologies.
> 
> > 
> > Right now www.kernel.org/git is unusable for me with lynx as it keeps 
> > prompting:
> > 
> > 	application/xhtml+xml  D)ownload, or C)ancel
> > 
> > Is there any plan to have that fixed?
> > 
> 
> Well there are a couple of quick thoughts, so far (in my quick testing)
> lynx and IE are the only two browsers that have issues with this
> particular bit of code.  Links, konqueror, safari, firefox, mozilla, etc
> all seem to handle the pages without issue.

No.  You also missed that links, elinks, and the emacs one (w3m or the 
like) were also reported to fail.  And sometimes lynx even works.

>  Taking a quick glance at the code it seems IE claims to be xhtml+xml 
> compliant but apparently isn't really (any real surprise?) and lynx 
> just doesn't seem to support that mime type.

Lynx and many others.  It is just a question of luch whether the served 
page is acceptable or not.

> The simplest fix would be to eliminate the distinction between
> applicatoin/xhtml+xml and application/html in the gitweb code (or at
> least in the caching gitweb code) and have everything claim a mimetype
> of application/html and let the browser sort out if it's using xhtml or
> html from the doctype.  This would solve both the problem your seeing on
> lynx and would make the caching gitweb usable by more IE users.

Great.


Nicolas

Re: bug with gitweb on kernel.org

[J.H.]

[-- Attachment #1: Type: text/plain, Size: 3879 bytes --]

On Sun, 2007-04-22 at 21:16 -0400, Nicolas Pitre wrote:
> On Sun, 22 Apr 2007, J.H. wrote:
> 
> > On Thu, 2007-04-19 at 23:02 -0400, Nicolas Pitre wrote:
> > > Almost 2 months ago we discussed about gitweb not properly detecting the 
> > > client's ability to deal with application/xhtml+xml, something to do 
> > > with the caching of a previous request from a client which did support 
> > > it and serving the same content to a subsequent client which does not.
> > 
> > I apparently missed that entire conversation, my apologies.
> > 
> > > 
> > > Right now www.kernel.org/git is unusable for me with lynx as it keeps 
> > > prompting:
> > > 
> > > 	application/xhtml+xml  D)ownload, or C)ancel
> > > 
> > > Is there any plan to have that fixed?
> > > 
> > 
> > Well there are a couple of quick thoughts, so far (in my quick testing)
> > lynx and IE are the only two browsers that have issues with this
> > particular bit of code.  Links, konqueror, safari, firefox, mozilla, etc
> > all seem to handle the pages without issue.
> 
> No.  You also missed that links, elinks, and the emacs one (w3m or the 
> like) were also reported to fail.  And sometimes lynx even works.

A more detailed set of tests (cache file included as attachment for
those curious, also the cache file was set as read only after it was
generated by epiphany so it was not regenerated during testing):

- epiphany v.2.16.3		- passed
- elinks v.0.11.1-5.1		- passed
- elinks v.0.4.2		- failed
- lynx v.2.8.5rel.1		- failed
- lynx v.2.8.5dev.7		- failed
- konqueror v.3.5.6-0.3.fc6	- passed
- konqueror v.3.1-13 Red Hat	- passed
- I.E. v.6.0.3790.1830 (2k3)	- passed
- I.E. v.6.0.2900.2180.xpsp_sp2_gdr.070227-2254	- failed
- w3m v.0.5.1			- failed
- w3m v.0.3.2.2			- failed
- firefox v.1.5.0.10		- passed
- Seamonkey v.1.8.1.2pre	- passed
- Mozilla v.1.7.13		- passed
- Mozilla v.1.4.2		- passed
- safari v.1.0.3		- 50/50 - loads but doesn't render anything after
description link (viewing source shows missing content)

Thats everything I have immediate access to (installed and up and
running) - if we need more data points I can start installing older
versions of netscape and even backtrack through several version of IE
(win95,win98,winME,win2k) but my guess is that most of the gecko based
platforms that are even remotely recent are fine, same goes for
konqueror.  I.E. is horked on XP until I.E. 7, win2k3 has a fix for this
already.  eLinks seems to be handling it with something relatively
recent.  And more or less everything else isn't handling the mime type.


> 
> >  Taking a quick glance at the code it seems IE claims to be xhtml+xml 
> > compliant but apparently isn't really (any real surprise?) and lynx 
> > just doesn't seem to support that mime type.
> 
> Lynx and many others.  It is just a question of luch whether the served 
> page is acceptable or not.

Well the only difference in the pages being served is the mime type
application/html vs. application/xhtml+xml.  Does anyone know the
original impetus to using application/xhtml+xml (despite the fact that
it's technically the correct choice) vs. just using application/html for
everything?  I'm sure there was a good reason behind it and I'd rather
know what that reason was before I got changing things

> 
> > The simplest fix would be to eliminate the distinction between
> > applicatoin/xhtml+xml and application/html in the gitweb code (or at
> > least in the caching gitweb code) and have everything claim a mimetype
> > of application/html and let the browser sort out if it's using xhtml or
> > html from the doctype.  This would solve both the problem your seeing on
> > lynx and would make the caching gitweb usable by more IE users.
> 
> Great.

I'm going to wait for further comment, if I don't see anything by the
end of Monday (PDT) I'll go ahead and make the change and get it out to
kernel.org.

- John

[-- Attachment #2: 3fe1ec2ea3145ad84038d09f5865f8a3 --]
[-- Type: text/plain, Size: 3310 bytes --]

Status: 200 OK
Content-Type: application/xhtml+xml

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US" lang="en-US">
<!-- git web interface version 1.5.0.rc0.g6369-dirty, (C) 2005-2006, Kay Sievers <kay.sievers@vrfy.org>, Christian Gierke -->
<!-- git core binaries version 1.5.0.rc0.g6369-dirty -->
<head>
<meta http-equiv="content-type" content="application/xhtml+xml; charset=utf-8"/>
<meta name="generator" content="gitweb/1.5.0.rc0.g6369-dirty git/1.5.0.rc0.g6369-dirty"/>
<meta name="robots" content="index, nofollow"/>
<title>Warthog9's Home</title>
<link rel="stylesheet" type="text/css" href="../gitweb-2/gitweb.css"/>
<link rel="alternate" title="Warthog9's Home projects list" href="/gitweb/gitweb/gitweb.cgi?a=project_index" type="text/plain; charset=utf-8"/>
<link rel="alternate" title="Warthog9's Home projects feeds" href="/gitweb/gitweb/gitweb.cgi?a=opml" type="text/x-opml"/>
<link rel="shortcut icon" href="../gitweb-2/git-favicon.png" type="image/png"/>
</head>
<body>
<div class="page_header">
<a title="git homepage" href="http://git.or.cz/"><img src="../gitweb-2/git-logo.png" width="72" height="27" alt="git" class="logo"/></a><a href="/gitweb/gitweb/gitweb.cgi">warthog9 test gitweb</a> / </div>
<table class="project_list">
<tr>
<th>Project</th>
<th><a class="header" href="/gitweb/gitweb/gitweb.cgi?o=descr">Description</a></th>
<th><a class="header" href="/gitweb/gitweb/gitweb.cgi?o=owner">Owner</a></th>
<th><a class="header" href="/gitweb/gitweb/gitweb.cgi?o=age">Last Change</a></th>
<th></th>
</tr>
<tr class="dark">
<td><a class="list" href="/gitweb/gitweb/gitweb.cgi?p=git.git;a=summary">git.git</a></td>
<td><a class="list" title="Unnamed repository; edit this file to name it for gitweb." href="/gitweb/gitweb/gitweb.cgi?p=git.git;a=summary">Unnamed repository; edit this ...</a></td>
<td><i>John Hawley</i></td>
<td class="age2">4 months ago</td>
<td class="link"><a href="/gitweb/gitweb/gitweb.cgi?p=git.git;a=summary">summary</a> | <a href="/gitweb/gitweb/gitweb.cgi?p=git.git;a=shortlog">shortlog</a> | <a href="/gitweb/gitweb/gitweb.cgi?p=git.git;a=log">log</a> | <a href="/gitweb/gitweb/gitweb.cgi?p=git.git;a=tree">tree</a> | <a href="git://git.kernel.org/pub/scm/git.git">git</a></td>
</tr>
<tr class="light">
<td><a class="list" href="/gitweb/gitweb/gitweb.cgi?p=git/.git;a=summary">git/.git</a></td>
<td><a class="list" title="Unnamed repository; edit this file to name it for gitweb." href="/gitweb/gitweb/gitweb.cgi?p=git/.git;a=summary">Unnamed repository; edit this ...</a></td>
<td><i>John Hawley</i></td>
<td class="age2">4 months ago</td>
<td class="link"><a href="/gitweb/gitweb/gitweb.cgi?p=git/.git;a=summary">summary</a> | <a href="/gitweb/gitweb/gitweb.cgi?p=git/.git;a=shortlog">shortlog</a> | <a href="/gitweb/gitweb/gitweb.cgi?p=git/.git;a=log">log</a> | <a href="/gitweb/gitweb/gitweb.cgi?p=git/.git;a=tree">tree</a> | <a href="git://git.kernel.org/pub/scm/git/.git">git</a></td>
</tr>
</table>
<div class="page_footer">
<a class="rss_logo" href="/gitweb/gitweb/gitweb.cgi?a=opml">OPML</a> <a class="rss_logo" href="/gitweb/gitweb/gitweb.cgi?a=project_index">TXT</a>
</div>
</body>
</html>

Re: bug with gitweb on kernel.org

[H. Peter Anvin]

J.H. wrote:
> 
> Well the only difference in the pages being served is the mime type
> application/html vs. application/xhtml+xml.  Does anyone know the
> original impetus to using application/xhtml+xml (despite the fact that
> it's technically the correct choice) vs. just using application/html for
> everything?  I'm sure there was a good reason behind it and I'd rather
> know what that reason was before I got changing things
> 

Presumably the motivation is so you know ahead of time that you can 
invoke an XML parser rather than an SGML/HTML parser.

Note: http://www.w3.org/TR/xhtml-media-types/ states that text/html is 
considered acceptable for HTML-compatible XHTML 1.0 but no other version 
of XHTML 1.0.  One of the main issues with making XHTML 1.0-compatible 
is to make sure there is a space before the final / in the last 
singleton: <foo /> rather than <foo/>

	-hpa

Re: bug with gitweb on kernel.org

[H. Peter Anvin]

H. Peter Anvin wrote:
> 
> Presumably the motivation is so you know ahead of time that you can 
> invoke an XML parser rather than an SGML/HTML parser.
> 
> Note: http://www.w3.org/TR/xhtml-media-types/ states that text/html is 
> considered acceptable for HTML-compatible XHTML 1.0 but no other version 
> of XHTML 1.0.  One of the main issues with making XHTML 1.0-compatible 
> is to make sure there is a space before the final / in the last 
> singleton: <foo /> rather than <foo/>
> 

This might also be useful reading:

http://www.mozilla.org/docs/web-developer/faq.html#xhtmldiff

	-hpa

Re: bug with gitweb on kernel.org

[Johan Herland]

On Tuesday 24 April 2007, H. Peter Anvin wrote:
> H. Peter Anvin wrote:
> > Presumably the motivation is so you know ahead of time that you can
> > invoke an XML parser rather than an SGML/HTML parser.
> >
> > Note: http://www.w3.org/TR/xhtml-media-types/ states that text/html
> > is considered acceptable for HTML-compatible XHTML 1.0 but no other
> > version of XHTML 1.0.  One of the main issues with making XHTML
> > 1.0-compatible is to make sure there is a space before the final /
> > in the last singleton: <foo /> rather than <foo/>
>
> This might also be useful reading:
>
> http://www.mozilla.org/docs/web-developer/faq.html#xhtmldiff

Along with these:

The W3C HTML and XHTML FAQ: 
http://www.w3.org/MarkUp/2004/xhtml-faq

This document seems to always be referenced in these discussions: 
http://www.hixie.ch/advocacy/xhtml


Have fun!

...Johan

-- 
Johan Herland, <johherla@online.no>
www.herland.net

Re: bug with gitweb on kernel.org

[Jakub Narebski]

J.H. wrote:

> Well the only difference in the pages being served is the mime type
> application/html vs. application/xhtml+xml.  Does anyone know the
> original impetus to using application/xhtml+xml (despite the fact that
> it's technically the correct choice) vs. just using application/html for
> everything?  I'm sure there was a good reason behind it and I'd rather
> know what that reason was before I got changing things

The idea was to serve application/xhtml+xml to browsers which _explicitely_
support it. But coupled with the fact that gitweb on kernel.org is modified
gitweb with caching, and it looks like it caches also HTTP headers...
I think simplest solution would be to remove complication, and always serve
text/html (at least for kernel.org gitweb with caching modifications).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: bug with gitweb on kernel.org

[J.H.]

On Tue, 2007-04-24 at 03:06 +0200, Jakub Narebski wrote:
> J.H. wrote:
> 
> > Well the only difference in the pages being served is the mime type
> > application/html vs. application/xhtml+xml.  Does anyone know the
> > original impetus to using application/xhtml+xml (despite the fact that
> > it's technically the correct choice) vs. just using application/html for
> > everything?  I'm sure there was a good reason behind it and I'd rather
> > know what that reason was before I got changing things
> 
> The idea was to serve application/xhtml+xml to browsers which _explicitely_
> support it. But coupled with the fact that gitweb on kernel.org is modified
> gitweb with caching, and it looks like it caches also HTTP headers...
> I think simplest solution would be to remove complication, and always serve
> text/html (at least for kernel.org gitweb with caching modifications).
> 

It's either that or store only the data not the headers and deal with
the headers on each request - but that might have other unintended
consequences I haven't thought of yet.  Anyway I think your right -
short term solution if nothing else is serve out text/html and look more
closely at the problem when I rebase.

- John 'Warthog9' Hawley

Re: bug with gitweb on kernel.org

[Johan Herland]

On Tuesday 24 April 2007, J.H. wrote:
> On Tue, 2007-04-24 at 03:06 +0200, Jakub Narebski wrote:
> > J.H. wrote:
> > > Well the only difference in the pages being served is the mime
> > > type application/html vs. application/xhtml+xml.  Does anyone
> > > know the original impetus to using application/xhtml+xml (despite
> > > the fact that it's technically the correct choice) vs. just using
> > > application/html for everything?  I'm sure there was a good
> > > reason behind it and I'd rather know what that reason was before
> > > I got changing things
> >
> > The idea was to serve application/xhtml+xml to browsers which
> > _explicitely_ support it. But coupled with the fact that gitweb on
> > kernel.org is modified gitweb with caching, and it looks like it
> > caches also HTTP headers... I think simplest solution would be to
> > remove complication, and always serve text/html (at least for
> > kernel.org gitweb with caching modifications).
>
> It's either that or store only the data not the headers and deal with
> the headers on each request - but that might have other unintended
> consequences I haven't thought of yet.  Anyway I think your right -
> short term solution if nothing else is serve out text/html and look
> more closely at the problem when I rebase.

Actually, if the caching mechanism supports the spec properly 
(specifically RFC 2616, section 14.44), you should be able to work 
around this, without disabling the cache:

You can return different responses to different clients as long as you 
use the HTTP Vary header (RFC 2616, section 14.44) to indicate the 
criteria for selecting which response to return.

Finally, you can use the client's HTTP Accept header to figure out 
whether the browser supports XHTML or not. Basically just check 
if "application/xhtml+xml" is listed with a greater (or equal, but 
non-zero) Q-value than "text/html". I have a simple snippet of python 
code that I use in my webapps for this purpose. It should be easily 
translatable to the language of your choice. However, The list's spam 
filter prevents me from attaching it here... :(

A similar solution using PHP is sketched out here: 
http://keystonewebsites.com/articles/mime_type.php


Have fun!

...Johan


-- 
Johan Herland, <johherla@online.no>
www.herland.net

Re: bug with gitweb on kernel.org

[J.H.]

On Tue, 2007-04-24 at 09:33 +0200, Johan Herland wrote:
> On Tuesday 24 April 2007, J.H. wrote:
> > On Tue, 2007-04-24 at 03:06 +0200, Jakub Narebski wrote:
> > > J.H. wrote:
> > > > Well the only difference in the pages being served is the mime
> > > > type application/html vs. application/xhtml+xml.  Does anyone
> > > > know the original impetus to using application/xhtml+xml (despite
> > > > the fact that it's technically the correct choice) vs. just using
> > > > application/html for everything?  I'm sure there was a good
> > > > reason behind it and I'd rather know what that reason was before
> > > > I got changing things
> > >
> > > The idea was to serve application/xhtml+xml to browsers which
> > > _explicitely_ support it. But coupled with the fact that gitweb on
> > > kernel.org is modified gitweb with caching, and it looks like it
> > > caches also HTTP headers... I think simplest solution would be to
> > > remove complication, and always serve text/html (at least for
> > > kernel.org gitweb with caching modifications).
> >
> > It's either that or store only the data not the headers and deal with
> > the headers on each request - but that might have other unintended
> > consequences I haven't thought of yet.  Anyway I think your right -
> > short term solution if nothing else is serve out text/html and look
> > more closely at the problem when I rebase.
> 
> Actually, if the caching mechanism supports the spec properly 
> (specifically RFC 2616, section 14.44), you should be able to work 
> around this, without disabling the cache:
> 
> You can return different responses to different clients as long as you 
> use the HTTP Vary header (RFC 2616, section 14.44) to indicate the 
> criteria for selecting which response to return.
> 
> Finally, you can use the client's HTTP Accept header to figure out 
> whether the browser support XHTML or not. Basically just check 
> if "application/xhtml+xml" is listed with a greater (or equal, but 
> non-zero) Q-value than "text/html". I've attached a snippet of python 
> code that I use in my webapps for this purpose. It should be easily 
> translatable to the language of your choice.
> 
> A similar solution using PHP is sketched out here: 
> http://keystonewebsites.com/articles/mime_type.php
> 

I'm not even remotely following a normal caching RFC.  The code is all
up online if you want to look at it
http://git.kernel.org/?p=git/warthog9/gitweb.git;a=summary it's not
pretty but it works, and if nothing else it will give me a decent number
of data points and such for when I do the rebase that I can take into
consideration.

- John

Re: bug with gitweb on kernel.org

[Johan Herland]

On Monday 23 April 2007, J.H. wrote:
> A more detailed set of tests (cache file included as attachment for
> those curious, also the cache file was set as read only after it was
> generated by epiphany so it was not regenerated during testing):
>
> - epiphany v.2.16.3		- passed
> - elinks v.0.11.1-5.1		- passed
> - elinks v.0.4.2		- failed
> - lynx v.2.8.5rel.1		- failed
> - lynx v.2.8.5dev.7		- failed
> - konqueror v.3.5.6-0.3.fc6	- passed
> - konqueror v.3.1-13 Red Hat	- passed
> - I.E. v.6.0.3790.1830 (2k3)	- passed
> - I.E. v.6.0.2900.2180.xpsp_sp2_gdr.070227-2254	- failed
> - w3m v.0.5.1			- failed
> - w3m v.0.3.2.2			- failed
> - firefox v.1.5.0.10		- passed
> - Seamonkey v.1.8.1.2pre	- passed
> - Mozilla v.1.7.13		- passed
> - Mozilla v.1.4.2		- passed
> - safari v.1.0.3		- 50/50 - loads but doesn't render anything after
> description link (viewing source shows missing content)
>
> Thats everything I have immediate access to (installed and up and
> running) - if we need more data points I can start installing older
> versions of netscape and even backtrack through several version of IE
> (win95,win98,winME,win2k) but my guess is that most of the gecko
> based platforms that are even remotely recent are fine, same goes for
> konqueror.  I.E. is horked on XP until I.E. 7, win2k3 has a fix for
> this already.  eLinks seems to be handling it with something
> relatively recent.  And more or less everything else isn't handling
> the mime type.

Others have done this testing before: 
http://www.w3.org/People/mimasa/test/xhtml/media-types/results


Have fun!

...Johan

-- 
Johan Herland, <johherla@online.no>
www.herland.net

Re: bug with gitweb on kernel.org

[J.H.]

Ok the change is out and in the wild it will likely take about 24hrs to
work itself through everything.  I'll check on it tomorrow to see how
things are going.

- John 'Warthog9' Hawley

On Sun, 2007-04-22 at 21:16 -0400, Nicolas Pitre wrote:
> On Sun, 22 Apr 2007, J.H. wrote:
> 
> > On Thu, 2007-04-19 at 23:02 -0400, Nicolas Pitre wrote:
> > > Almost 2 months ago we discussed about gitweb not properly detecting the 
> > > client's ability to deal with application/xhtml+xml, something to do 
> > > with the caching of a previous request from a client which did support 
> > > it and serving the same content to a subsequent client which does not.
> > 
> > I apparently missed that entire conversation, my apologies.
> > 
> > > 
> > > Right now www.kernel.org/git is unusable for me with lynx as it keeps 
> > > prompting:
> > > 
> > > 	application/xhtml+xml  D)ownload, or C)ancel
> > > 
> > > Is there any plan to have that fixed?
> > > 
> > 
> > Well there are a couple of quick thoughts, so far (in my quick testing)
> > lynx and IE are the only two browsers that have issues with this
> > particular bit of code.  Links, konqueror, safari, firefox, mozilla, etc
> > all seem to handle the pages without issue.
> 
> No.  You also missed that links, elinks, and the emacs one (w3m or the 
> like) were also reported to fail.  And sometimes lynx even works.
> 
> >  Taking a quick glance at the code it seems IE claims to be xhtml+xml 
> > compliant but apparently isn't really (any real surprise?) and lynx 
> > just doesn't seem to support that mime type.
> 
> Lynx and many others.  It is just a question of luch whether the served 
> page is acceptable or not.
> 
> > The simplest fix would be to eliminate the distinction between
> > applicatoin/xhtml+xml and application/html in the gitweb code (or at
> > least in the caching gitweb code) and have everything claim a mimetype
> > of application/html and let the browser sort out if it's using xhtml or
> > html from the doctype.  This would solve both the problem your seeing on
> > lynx and would make the caching gitweb usable by more IE users.
> 
> Great.
> 
> 
> Nicolas
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html