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
next prev 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).