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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.