Gitweb intermittently serves ISO-8859-1 with UTF-8 headers.

Setting the component.

The problem is intermittent.

In ~ 50% of cases I receive a C3 A1 (valid UTF-8 for U+00E1) and sometimes E1 (ISO 8859-1) for wget http://drupalcode.org/project/drupal.git/shortlog/refs/heads/6.x.

As the page is always served with a UTF-8 header, the E1 variant will display as a question mark.

So it's probably a caching issue.

I can confirm the behavior described by Heine. It's simply inconsistent.

Duplicating #1069064: wrong accentuated character in Full Name in favour of this.

As noted in #1075976: No UTF8 love on git (after searching for UTF8 in the issue names list *hint* *hint* Gábor ;))

It can't be a caching issue, since i never ever created a project on drupal before.

As we have no idea what, if any, caching is between user and git I doubt we can rule out anything.

It definitely a caching issue. The first time a page is generated it is sent in ISO-8859-1, any subsequent time is ok. Just refreshing the page generally fixes the issue.

Yeah, that is BIZARRE. I wonder why we never saw this on staging.

It is indeed a caching issue. Today I noticed the timestamps in the footer. I've refreshed a bit and recorded the them:

Cache Last Updated: Thu Mar 10 09:36:20 2011 GMT -> ISO
Cache Last Updated: Thu Mar 10 09:36:56 2011 GMT -> ISO
Cache Last Updated: Thu Mar 10 09:36:56 2011 GMT -> UTF-8 (*)

Cache Last Updated: Thu Mar 10 09:37:24 2011 GMT -> ISO
Cache Last Updated: Thu Mar 10 09:37:24 2011 GMT -> UTF-8 (*)

Cache Last Updated: Thu Mar 10 09:39:33 2011 GMT -> ISO
Cache Last Updated: Thu Mar 10 09:39:33 2011 GMT -> UTF-8 (*)

It appears as though any request served from cache is OK.

What version & fork of gitweb is used on http://git.drupal.org/ ?

neclimdul and nnewton arethe two folks who could answer what version & fork of gitweb is used on http://git.drupal.org/ ?

I confirm that the issue also happens to me (damn french! ;) here:

http://drupalcode.org/project/hostmaster.git

... and is intermittent. I also confirm the problem is with non-cached versions: when the page is cached, it renders fine.

A workaround is to reset the encoding in your browser, which is odd because it's *already* set to utf8... Maybe that's because the page gets reloaded when you change the encoding in Chromium 6.x.

In fact, retracing the headers, it seems that with or without the cache, gitweb sends the proper headers:

HTTP/1.1 200 OK
Date: Wed, 23 Mar 2011 03:21:27 GMT
Server: Apache/2.2.3 (CentOS)
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 3096
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8

That's without the cache, but with the cache I still get:

HTTP/1.1 200 OK
Date: Wed, 23 Mar 2011 03:22:16 GMT
Server: Apache/2.2.3 (CentOS)
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 3099
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8

Notice the size difference because of UTF8. It's therefore the *data* that's latin1, not the headers (which are set right). I actually verified that with curl -v. It's as if the generated page was latin1 but then cached as utf8...

There are quite a few issues with utf8 in gitweb historically it seems, but this seems to be most relevant, even if old:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487465

We'd need to know the version to go forward from here...

I agree that it's not the headers, but the actual data that's mis-encoded:
http://drupalcode.org/project/google_analytics_reports.git/commit/31c8691

git log | xxd

0xC3A1 is unicode.

curl | xxd

0xE1 is Latin-1 / Windows-1252.

gitweb