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@xxxxxxxxx> www.herland.net - 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