{"thread":{"id":"7747","subject":"bug with gitweb on kernel.org","startedAt":"2007-04-20T03:02:21Z","lastAt":"2007-04-24T08:19:48Z","messageCount":13,"participants":["Nicolas Pitre","J.H.","H. Peter Anvin","Jakub Narebski","Johan Herland"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"39936","messageId":"alpine.LFD.0.98.0704192255180.4504@xanadu.home","threadId":"7747","inReplyTo":null,"subject":"bug with gitweb on kernel.org","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-04-20T03:02:21Z","receivedAt":"2007-04-20T03:02:21Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"Almost 2 months ago we discussed about gitweb not properly detecting the \nclient's ability to deal with application/xhtml+xml, something to do \nwith the caching of a previous request from a client which did support \nit and serving the same content to a subsequent client which does not.\n\nRight now www.kernel.org/git is unusable for me with lynx as it keeps \nprompting:\n\n\tapplication/xhtml+xml D)ownload, or C)ancel\n\nIs there any plan to have that fixed?\n\n\nNicolas\n"},{"id":"40167","messageId":"1177286943.24896.14.camel@localhost.localdomain","threadId":"7747","inReplyTo":"alpine.LFD.0.98.0704192255180.4504@xanadu.home","subject":"Re: bug with gitweb on kernel.org","fromName":"J.H.","fromEmail":"warthog19@eaglescrag.net","sentAt":"2007-04-23T00:09:03Z","receivedAt":"2007-04-23T00:09:03Z","isPatch":false,"sender":{"key":"warthog19@eaglescrag.net","avatar":null},"body":"On Thu, 2007-04-19 at 23:02 -0400, Nicolas Pitre wrote:\n> Almost 2 months ago we discussed about gitweb not properly detecting the \n> client's ability to deal with application/xhtml+xml, something to do \n> with the caching of a previous request from a client which did support \n> it and serving the same content to a subsequent client which does not.\n\nI apparently missed that entire conversation, my apologies.\n\n> \n> Right now www.kernel.org/git is unusable for me with lynx as it keeps \n> prompting:\n> \n> \tapplication/xhtml+xml D)ownload, or C)ancel\n> \n> Is there any plan to have that fixed?\n> \n\nWell there are a couple of quick thoughts, so far (in my quick testing)\nlynx and IE are the only two browsers that have issues with this\nparticular bit of code. Links, konqueror, safari, firefox, mozilla, etc\nall seem to handle the pages without issue. Taking a quick glance at\nthe code it seems IE claims to be xhtml+xml compliant but apparently\nisn't really (any real surprise?) and lynx just doesn't seem to support\nthat mime type.\n\nThe simplest fix would be to eliminate the distinction between\napplicatoin/xhtml+xml and application/html in the gitweb code (or at\nleast in the caching gitweb code) and have everything claim a mimetype\nof application/html and let the browser sort out if it's using xhtml or\nhtml from the doctype. This would solve both the problem your seeing on\nlynx and would make the caching gitweb usable by more IE users.\n\nSome quick testing on my part seems to indicate this doesn't break\nbehavior for any of the clients I have access to, but I thought I'd\ncheck and see if anyone had any concerns over this particular change\nbefore I barrel ahead with it in the caching gitweb code.\n\n- John 'Warthog9' Hawley\n"},{"id":"40172","messageId":"alpine.LFD.0.98.0704222112040.28339@xanadu.home","threadId":"7747","inReplyTo":"1177286943.24896.14.camel@localhost.localdomain","subject":"Re: bug with gitweb on kernel.org","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-04-23T01:16:45Z","receivedAt":"2007-04-23T01:16:45Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sun, 22 Apr 2007, J.H. wrote:\n\n> On Thu, 2007-04-19 at 23:02 -0400, Nicolas Pitre wrote:\n> > Almost 2 months ago we discussed about gitweb not properly detecting the \n> > client's ability to deal with application/xhtml+xml, something to do \n> > with the caching of a previous request from a client which did support \n> > it and serving the same content to a subsequent client which does not.\n> \n> I apparently missed that entire conversation, my apologies.\n> \n> > \n> > Right now www.kernel.org/git is unusable for me with lynx as it keeps \n> > prompting:\n> > \n> > \tapplication/xhtml+xml D)ownload, or C)ancel\n> > \n> > Is there any plan to have that fixed?\n> > \n> \n> Well there are a couple of quick thoughts, so far (in my quick testing)\n> lynx and IE are the only two browsers that have issues with this\n> particular bit of code. Links, konqueror, safari, firefox, mozilla, etc\n> all seem to handle the pages without issue.\n\nNo. You also missed that links, elinks, and the emacs one (w3m or the \nlike) were also reported to fail. And sometimes lynx even works.\n\n> Taking a quick glance at the code it seems IE claims to be xhtml+xml \n> compliant but apparently isn't really (any real surprise?) and lynx \n> just doesn't seem to support that mime type.\n\nLynx and many others. It is just a question of luch whether the served \npage is acceptable or not.\n\n> The simplest fix would be to eliminate the distinction between\n> applicatoin/xhtml+xml and application/html in the gitweb code (or at\n> least in the caching gitweb code) and have everything claim a mimetype\n> of application/html and let the browser sort out if it's using xhtml or\n> html from the doctype. This would solve both the problem your seeing on\n> lynx and would make the caching gitweb usable by more IE users.\n\nGreat.\n\n\nNicolas\n"},{"id":"40173","messageId":"1177294925.24896.48.camel@localhost.localdomain","threadId":"7747","inReplyTo":"alpine.LFD.0.98.0704222112040.28339@xanadu.home","subject":"Re: bug with gitweb on kernel.org","fromName":"J.H.","fromEmail":"warthog19@eaglescrag.net","sentAt":"2007-04-23T02:22:05Z","receivedAt":"2007-04-23T02:22:05Z","isPatch":false,"sender":{"key":"warthog19@eaglescrag.net","avatar":null},"body":"On Sun, 2007-04-22 at 21:16 -0400, Nicolas Pitre wrote:\n> On Sun, 22 Apr 2007, J.H. wrote:\n> \n> > On Thu, 2007-04-19 at 23:02 -0400, Nicolas Pitre wrote:\n> > > Almost 2 months ago we discussed about gitweb not properly detecting the \n> > > client's ability to deal with application/xhtml+xml, something to do \n> > > with the caching of a previous request from a client which did support \n> > > it and serving the same content to a subsequent client which does not.\n> > \n> > I apparently missed that entire conversation, my apologies.\n> > \n> > > \n> > > Right now www.kernel.org/git is unusable for me with lynx as it keeps \n> > > prompting:\n> > > \n> > > \tapplication/xhtml+xml D)ownload, or C)ancel\n> > > \n> > > Is there any plan to have that fixed?\n> > > \n> > \n> > Well there are a couple of quick thoughts, so far (in my quick testing)\n> > lynx and IE are the only two browsers that have issues with this\n> > particular bit of code. Links, konqueror, safari, firefox, mozilla, etc\n> > all seem to handle the pages without issue.\n> \n> No. You also missed that links, elinks, and the emacs one (w3m or the \n> like) were also reported to fail. And sometimes lynx even works.\n\nA more detailed set of tests (cache file included as attachment for\nthose curious, also the cache file was set as read only after it was\ngenerated by epiphany so it was not regenerated during testing):\n\n- epiphany v.2.16.3\t\t- passed\n- elinks v.0.11.1-5.1\t\t- passed\n- elinks v.0.4.2\t\t- failed\n- lynx v.2.8.5rel.1\t\t- failed\n- lynx v.2.8.5dev.7\t\t- failed\n- konqueror v.3.5.6-0.3.fc6\t- passed\n- konqueror v.3.1-13 Red Hat\t- passed\n- I.E. v.6.0.3790.1830 (2k3)\t- passed\n- I.E. v.6.0.2900.2180.xpsp_sp2_gdr.070227-2254\t- failed\n- w3m v.0.5.1\t\t\t- failed\n- w3m v.0.3.2.2\t\t\t- failed\n- firefox v.1.5.0.10\t\t- passed\n- Seamonkey v.1.8.1.2pre\t- passed\n- Mozilla v.1.7.13\t\t- passed\n- Mozilla v.1.4.2\t\t- passed\n- safari v.1.0.3\t\t- 50/50 - loads but doesn't render anything after\ndescription link (viewing source shows missing content)\n\nThats everything I have immediate access to (installed and up and\nrunning) - if we need more data points I can start installing older\nversions of netscape and even backtrack through several version of IE\n(win95,win98,winME,win2k) but my guess is that most of the gecko based\nplatforms that are even remotely recent are fine, same goes for\nkonqueror. I.E. is horked on XP until I.E. 7, win2k3 has a fix for this\nalready. eLinks seems to be handling it with something relatively\nrecent. And more or less everything else isn't handling the mime type.\n\n\n> \n> > Taking a quick glance at the code it seems IE claims to be xhtml+xml \n> > compliant but apparently isn't really (any real surprise?) and lynx \n> > just doesn't seem to support that mime type.\n> \n> Lynx and many others. It is just a question of luch whether the served \n> page is acceptable or not.\n\nWell the only difference in the pages being served is the mime type\napplication/html vs. application/xhtml+xml. Does anyone know the\noriginal impetus to using application/xhtml+xml (despite the fact that\nit's technically the correct choice) vs. just using application/html for\neverything? I'm sure there was a good reason behind it and I'd rather\nknow what that reason was before I got changing things\n\n> \n> > The simplest fix would be to eliminate the distinction between\n> > applicatoin/xhtml+xml and application/html in the gitweb code (or at\n> > least in the caching gitweb code) and have everything claim a mimetype\n> > of application/html and let the browser sort out if it's using xhtml or\n> > html from the doctype. This would solve both the problem your seeing on\n> > lynx and would make the caching gitweb usable by more IE users.\n> \n> Great.\n\nI'm going to wait for further comment, if I don't see anything by the\nend of Monday (PDT) I'll go ahead and make the change and get it out to\nkernel.org.\n\n- John\n\n\nStatus: 200 OK\nContent-Type: application/xhtml+xml\n\n\n\n\n\n\n\n\n\n\nWarthog9's Home\n\n\n\n\n\n\n
\n\"git\"warthog9 test gitweb /
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ProjectDescriptionOwnerLast Change
git.gitUnnamed repository; edit this ...John Hawley4 months agosummary | shortlog | log | tree | git
git/.gitUnnamed repository; edit this ...John Hawley4 months agosummary | shortlog | log | tree | git
\n
\nOPML TXT\n
\n\n"},{"id":"40266","messageId":"462D4CEC.6010204@zytor.com","threadId":"7747","inReplyTo":"1177294925.24896.48.camel@localhost.localdomain","subject":"Re: bug with gitweb on kernel.org","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-04-24T00:18:52Z","receivedAt":"2007-04-24T00:18:52Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"J.H. wrote:\n> \n> Well the only difference in the pages being served is the mime type\n> application/html vs. application/xhtml+xml. Does anyone know the\n> original impetus to using application/xhtml+xml (despite the fact that\n> it's technically the correct choice) vs. just using application/html for\n> everything? I'm sure there was a good reason behind it and I'd rather\n> know what that reason was before I got changing things\n> \n\nPresumably the motivation is so you know ahead of time that you can \ninvoke an XML parser rather than an SGML/HTML parser.\n\nNote: http://www.w3.org/TR/xhtml-media-types/ states that text/html is \nconsidered acceptable for HTML-compatible XHTML 1.0 but no other version \nof XHTML 1.0. One of the main issues with making XHTML 1.0-compatible \nis to make sure there is a space before the final / in the last \nsingleton: rather than \n\n\t-hpa\n"},{"id":"40270","messageId":"462D52F3.5050508@zytor.com","threadId":"7747","inReplyTo":"462D4CEC.6010204@zytor.com","subject":"Re: bug with gitweb on kernel.org","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-04-24T00:44:35Z","receivedAt":"2007-04-24T00:44:35Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"H. Peter Anvin wrote:\n> \n> Presumably the motivation is so you know ahead of time that you can \n> invoke an XML parser rather than an SGML/HTML parser.\n> \n> Note: http://www.w3.org/TR/xhtml-media-types/ states that text/html is \n> considered acceptable for HTML-compatible XHTML 1.0 but no other version \n> of XHTML 1.0. One of the main issues with making XHTML 1.0-compatible \n> is to make sure there is a space before the final / in the last \n> singleton: rather than \n> \n\nThis might also be useful reading:\n\nhttp://www.mozilla.org/docs/web-developer/faq.html#xhtmldiff\n\n\t-hpa\n"},{"id":"40276","messageId":"1177376808.5357.13.camel@localhost.localdomain","threadId":"7747","inReplyTo":"f0jkvm$31p$1@sea.gmane.org","subject":"Re: bug with gitweb on kernel.org","fromName":"J.H.","fromEmail":"warthog19@eaglescrag.net","sentAt":"2007-04-24T01:06:48Z","receivedAt":"2007-04-24T01:06:48Z","isPatch":false,"sender":{"key":"warthog19@eaglescrag.net","avatar":null},"body":"On Tue, 2007-04-24 at 03:06 +0200, Jakub Narebski wrote:\n> J.H. wrote:\n> \n> > Well the only difference in the pages being served is the mime type\n> > application/html vs. application/xhtml+xml. Does anyone know the\n> > original impetus to using application/xhtml+xml (despite the fact that\n> > it's technically the correct choice) vs. just using application/html for\n> > everything? I'm sure there was a good reason behind it and I'd rather\n> > know what that reason was before I got changing things\n> \n> The idea was to serve application/xhtml+xml to browsers which _explicitely_\n> support it. But coupled with the fact that gitweb on kernel.org is modified\n> gitweb with caching, and it looks like it caches also HTTP headers...\n> I think simplest solution would be to remove complication, and always serve\n> text/html (at least for kernel.org gitweb with caching modifications).\n> \n\nIt's either that or store only the data not the headers and deal with\nthe headers on each request - but that might have other unintended\nconsequences I haven't thought of yet. Anyway I think your right -\nshort term solution if nothing else is serve out text/html and look more\nclosely at the problem when I rebase.\n\n- John 'Warthog9' Hawley\n"},{"id":"40275","messageId":"f0jkvm$31p$1@sea.gmane.org","threadId":"7747","inReplyTo":"1177294925.24896.48.camel@localhost.localdomain","subject":"Re: bug with gitweb on kernel.org","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-04-24T01:06:51Z","receivedAt":"2007-04-24T01:06:51Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"J.H. wrote:\n\n> Well the only difference in the pages being served is the mime type\n> application/html vs. application/xhtml+xml.  Does anyone know the\n> original impetus to using application/xhtml+xml (despite the fact that\n> it's technically the correct choice) vs. just using application/html for\n> everything?  I'm sure there was a good reason behind it and I'd rather\n> know what that reason was before I got changing things\n\nThe idea was to serve application/xhtml+xml to browsers which _explicitely_\nsupport it. But coupled with the fact that gitweb on kernel.org is modified\ngitweb with caching, and it looks like it caches also HTTP headers...\nI think simplest solution would be to remove complication, and always serve\ntext/html (at least for kernel.org gitweb with caching modifications).\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"40296","messageId":"200704240840.12387.johherla@online.no","threadId":"7747","inReplyTo":"462D52F3.5050508@zytor.com","subject":"Re: bug with gitweb on kernel.org","fromName":"Johan Herland","fromEmail":"johherla@online.no","sentAt":"2007-04-24T06:40:12Z","receivedAt":"2007-04-24T06:40:12Z","isPatch":false,"sender":{"key":"johherla@online.no","avatar":"https://gravatar.com/avatar/987dcaf7b10800fd92fd741ca082c3430838d9c8c971901005c9facd545643ad?d=mp&s=160"},"body":"On Tuesday 24 April 2007, H. Peter Anvin wrote:\n> H. Peter Anvin wrote:\n> > Presumably the motivation is so you know ahead of time that you can\n> > invoke an XML parser rather than an SGML/HTML parser.\n> >\n> > Note: http://www.w3.org/TR/xhtml-media-types/ states that text/html\n> > is considered acceptable for HTML-compatible XHTML 1.0 but no other\n> > version of XHTML 1.0. One of the main issues with making XHTML\n> > 1.0-compatible is to make sure there is a space before the final /\n> > in the last singleton: rather than \n>\n> This might also be useful reading:\n>\n> http://www.mozilla.org/docs/web-developer/faq.html#xhtmldiff\n\nAlong with these:\n\nThe W3C HTML and XHTML FAQ: \nhttp://www.w3.org/MarkUp/2004/xhtml-faq\n\nThis document seems to always be referenced in these discussions: \nhttp://www.hixie.ch/advocacy/xhtml\n\n\nHave fun!\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"40297","messageId":"200704240842.17496.johherla@online.no","threadId":"7747","inReplyTo":"1177294925.24896.48.camel@localhost.localdomain","subject":"Re: bug with gitweb on kernel.org","fromName":"Johan Herland","fromEmail":"johherla@online.no","sentAt":"2007-04-24T06:42:17Z","receivedAt":"2007-04-24T06:42:17Z","isPatch":false,"sender":{"key":"johherla@online.no","avatar":"https://gravatar.com/avatar/987dcaf7b10800fd92fd741ca082c3430838d9c8c971901005c9facd545643ad?d=mp&s=160"},"body":"On Monday 23 April 2007, J.H. wrote:\n> A more detailed set of tests (cache file included as attachment for\n> those curious, also the cache file was set as read only after it was\n> generated by epiphany so it was not regenerated during testing):\n>\n> - epiphany v.2.16.3\t\t- passed\n> - elinks v.0.11.1-5.1\t\t- passed\n> - elinks v.0.4.2\t\t- failed\n> - lynx v.2.8.5rel.1\t\t- failed\n> - lynx v.2.8.5dev.7\t\t- failed\n> - konqueror v.3.5.6-0.3.fc6\t- passed\n> - konqueror v.3.1-13 Red Hat\t- passed\n> - I.E. v.6.0.3790.1830 (2k3)\t- passed\n> - I.E. v.6.0.2900.2180.xpsp_sp2_gdr.070227-2254\t- failed\n> - w3m v.0.5.1\t\t\t- failed\n> - w3m v.0.3.2.2\t\t\t- failed\n> - firefox v.1.5.0.10\t\t- passed\n> - Seamonkey v.1.8.1.2pre\t- passed\n> - Mozilla v.1.7.13\t\t- passed\n> - Mozilla v.1.4.2\t\t- passed\n> - safari v.1.0.3\t\t- 50/50 - loads but doesn't render anything after\n> description link (viewing source shows missing content)\n>\n> Thats everything I have immediate access to (installed and up and\n> running) - if we need more data points I can start installing older\n> versions of netscape and even backtrack through several version of IE\n> (win95,win98,winME,win2k) but my guess is that most of the gecko\n> based platforms that are even remotely recent are fine, same goes for\n> konqueror. I.E. is horked on XP until I.E. 7, win2k3 has a fix for\n> this already. eLinks seems to be handling it with something\n> relatively recent. And more or less everything else isn't handling\n> the mime type.\n\nOthers have done this testing before: \nhttp://www.w3.org/People/mimasa/test/xhtml/media-types/results\n\n\nHave fun!\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"40300","messageId":"200704240940.58948.johherla@online.no","threadId":"7747","inReplyTo":"1177376808.5357.13.camel@localhost.localdomain","subject":"Re: bug with gitweb on kernel.org","fromName":"Johan Herland","fromEmail":"johherla@online.no","sentAt":"2007-04-24T07:40:58Z","receivedAt":"2007-04-24T07:40:58Z","isPatch":false,"sender":{"key":"johherla@online.no","avatar":"https://gravatar.com/avatar/987dcaf7b10800fd92fd741ca082c3430838d9c8c971901005c9facd545643ad?d=mp&s=160"},"body":"On Tuesday 24 April 2007, J.H. wrote:\n> On Tue, 2007-04-24 at 03:06 +0200, Jakub Narebski wrote:\n> > J.H. wrote:\n> > > Well the only difference in the pages being served is the mime\n> > > type application/html vs. application/xhtml+xml. Does anyone\n> > > know the original impetus to using application/xhtml+xml (despite\n> > > the fact that it's technically the correct choice) vs. just using\n> > > application/html for everything? I'm sure there was a good\n> > > reason behind it and I'd rather know what that reason was before\n> > > I got changing things\n> >\n> > The idea was to serve application/xhtml+xml to browsers which\n> > _explicitely_ support it. But coupled with the fact that gitweb on\n> > kernel.org is modified gitweb with caching, and it looks like it\n> > caches also HTTP headers... I think simplest solution would be to\n> > remove complication, and always serve text/html (at least for\n> > kernel.org gitweb with caching modifications).\n>\n> It's either that or store only the data not the headers and deal with\n> the headers on each request - but that might have other unintended\n> consequences I haven't thought of yet. Anyway I think your right -\n> short term solution if nothing else is serve out text/html and look\n> more closely at the problem when I rebase.\n\nActually, if the caching mechanism supports the spec properly \n(specifically RFC 2616, section 14.44), you should be able to work \naround this, without disabling the cache:\n\nYou can return different responses to different clients as long as you \nuse the HTTP Vary header (RFC 2616, section 14.44) to indicate the \ncriteria for selecting which response to return.\n\nFinally, you can use the client's HTTP Accept header to figure out \nwhether the browser supports XHTML or not. Basically just check \nif \"application/xhtml+xml\" is listed with a greater (or equal, but \nnon-zero) Q-value than \"text/html\". I have a simple snippet of python \ncode that I use in my webapps for this purpose. It should be easily \ntranslatable to the language of your choice. However, The list's spam \nfilter prevents me from attaching it here... :(\n\nA similar solution using PHP is sketched out here: \nhttp://keystonewebsites.com/articles/mime_type.php\n\n\nHave fun!\n\n...Johan\n\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"40301","messageId":"1177401048.5357.27.camel@localhost.localdomain","threadId":"7747","inReplyTo":"200704240933.58680.johherla@online.no","subject":"Re: bug with gitweb on kernel.org","fromName":"J.H.","fromEmail":"warthog19@eaglescrag.net","sentAt":"2007-04-24T07:50:48Z","receivedAt":"2007-04-24T07:50:48Z","isPatch":false,"sender":{"key":"warthog19@eaglescrag.net","avatar":null},"body":"On Tue, 2007-04-24 at 09:33 +0200, Johan Herland wrote:\n> On Tuesday 24 April 2007, J.H. wrote:\n> > On Tue, 2007-04-24 at 03:06 +0200, Jakub Narebski wrote:\n> > > J.H. wrote:\n> > > > Well the only difference in the pages being served is the mime\n> > > > type application/html vs. application/xhtml+xml. Does anyone\n> > > > know the original impetus to using application/xhtml+xml (despite\n> > > > the fact that it's technically the correct choice) vs. just using\n> > > > application/html for everything? I'm sure there was a good\n> > > > reason behind it and I'd rather know what that reason was before\n> > > > I got changing things\n> > >\n> > > The idea was to serve application/xhtml+xml to browsers which\n> > > _explicitely_ support it. But coupled with the fact that gitweb on\n> > > kernel.org is modified gitweb with caching, and it looks like it\n> > > caches also HTTP headers... I think simplest solution would be to\n> > > remove complication, and always serve text/html (at least for\n> > > kernel.org gitweb with caching modifications).\n> >\n> > It's either that or store only the data not the headers and deal with\n> > the headers on each request - but that might have other unintended\n> > consequences I haven't thought of yet. Anyway I think your right -\n> > short term solution if nothing else is serve out text/html and look\n> > more closely at the problem when I rebase.\n> \n> Actually, if the caching mechanism supports the spec properly \n> (specifically RFC 2616, section 14.44), you should be able to work \n> around this, without disabling the cache:\n> \n> You can return different responses to different clients as long as you \n> use the HTTP Vary header (RFC 2616, section 14.44) to indicate the \n> criteria for selecting which response to return.\n> \n> Finally, you can use the client's HTTP Accept header to figure out \n> whether the browser support XHTML or not. Basically just check \n> if \"application/xhtml+xml\" is listed with a greater (or equal, but \n> non-zero) Q-value than \"text/html\". I've attached a snippet of python \n> code that I use in my webapps for this purpose. It should be easily \n> translatable to the language of your choice.\n> \n> A similar solution using PHP is sketched out here: \n> http://keystonewebsites.com/articles/mime_type.php\n> \n\nI'm not even remotely following a normal caching RFC. The code is all\nup online if you want to look at it\nhttp://git.kernel.org/?p=git/warthog9/gitweb.git;a=summary it's not\npretty but it works, and if nothing else it will give me a decent number\nof data points and such for when I do the rebase that I can take into\nconsideration.\n\n- John\n"},{"id":"40305","messageId":"1177402788.5357.30.camel@localhost.localdomain","threadId":"7747","inReplyTo":"alpine.LFD.0.98.0704222112040.28339@xanadu.home","subject":"Re: bug with gitweb on kernel.org","fromName":"J.H.","fromEmail":"warthog19@eaglescrag.net","sentAt":"2007-04-24T08:19:48Z","receivedAt":"2007-04-24T08:19:48Z","isPatch":false,"sender":{"key":"warthog19@eaglescrag.net","avatar":null},"body":"Ok the change is out and in the wild it will likely take about 24hrs to\nwork itself through everything. I'll check on it tomorrow to see how\nthings are going.\n\n- John 'Warthog9' Hawley\n\nOn Sun, 2007-04-22 at 21:16 -0400, Nicolas Pitre wrote:\n> On Sun, 22 Apr 2007, J.H. wrote:\n> \n> > On Thu, 2007-04-19 at 23:02 -0400, Nicolas Pitre wrote:\n> > > Almost 2 months ago we discussed about gitweb not properly detecting the \n> > > client's ability to deal with application/xhtml+xml, something to do \n> > > with the caching of a previous request from a client which did support \n> > > it and serving the same content to a subsequent client which does not.\n> > \n> > I apparently missed that entire conversation, my apologies.\n> > \n> > > \n> > > Right now www.kernel.org/git is unusable for me with lynx as it keeps \n> > > prompting:\n> > > \n> > > \tapplication/xhtml+xml D)ownload, or C)ancel\n> > > \n> > > Is there any plan to have that fixed?\n> > > \n> > \n> > Well there are a couple of quick thoughts, so far (in my quick testing)\n> > lynx and IE are the only two browsers that have issues with this\n> > particular bit of code. Links, konqueror, safari, firefox, mozilla, etc\n> > all seem to handle the pages without issue.\n> \n> No. You also missed that links, elinks, and the emacs one (w3m or the \n> like) were also reported to fail. And sometimes lynx even works.\n> \n> > Taking a quick glance at the code it seems IE claims to be xhtml+xml \n> > compliant but apparently isn't really (any real surprise?) and lynx \n> > just doesn't seem to support that mime type.\n> \n> Lynx and many others. It is just a question of luch whether the served \n> page is acceptable or not.\n> \n> > The simplest fix would be to eliminate the distinction between\n> > applicatoin/xhtml+xml and application/html in the gitweb code (or at\n> > least in the caching gitweb code) and have everything claim a mimetype\n> > of application/html and let the browser sort out if it's using xhtml or\n> > html from the doctype. This would solve both the problem your seeing on\n> > lynx and would make the caching gitweb usable by more IE users.\n> \n> Great.\n> \n> \n> Nicolas\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"}]}