git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "J.H." <warthog19@eaglescrag.net>
To: Johan Herland <johherla@online.no>
Cc: git@vger.kernel.org
Subject: Re: bug with gitweb on kernel.org
Date: Tue, 24 Apr 2007 00:50:48 -0700	[thread overview]
Message-ID: <1177401048.5357.27.camel@localhost.localdomain> (raw)
In-Reply-To: <200704240933.58680.johherla@online.no>

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

  parent reply	other threads:[~2007-04-24  7:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-20  3:02 bug with gitweb on kernel.org Nicolas Pitre
2007-04-23  0:09 ` J.H.
2007-04-23  1:16   ` Nicolas Pitre
2007-04-23  2:22     ` J.H.
2007-04-24  0:18       ` H. Peter Anvin
2007-04-24  0:44         ` H. Peter Anvin
2007-04-24  6:40           ` Johan Herland
2007-04-24  1:06       ` Jakub Narebski
2007-04-24  1:06         ` J.H.
2007-04-24  7:40           ` Johan Herland
     [not found]           ` <200704240933.58680.johherla@online.no>
2007-04-24  7:50             ` J.H. [this message]
2007-04-24  6:42       ` Johan Herland
2007-04-24  8:19     ` J.H.

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1177401048.5357.27.camel@localhost.localdomain \
    --to=warthog19@eaglescrag.net \
    --cc=git@vger.kernel.org \
    --cc=johherla@online.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).