Whenever you go to a "raw" URL like http://drupalcode.org/project/drupal.git/blob_plain/refs/heads/7.x:/CHAN... in Firefox 7, this happens:

Corrupted Content Error<br />
The page you are trying to view cannot be shown because an error in the data transmission was detected.<br />
The page you are trying to view cannot be shown because an error in the data transmission was detected. Please contact the website owners to inform them of this problem.

I believe we're running into this bug https://bugzilla.mozilla.org/show_bug.cgi?id=681140 or something like it.


Here are the HTTP headers:

GET /project/drupal.git/blob_plain/refs/heads/7.x:/CHANGELOG.txt HTTP/1.1
Host: drupalcode.org
Connection: keep-alive
Cache-Control: max-age=0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.202 Safari/535.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Don't see a double content-disposition there. Hm.

Haha. RESPONSE headers. Not request headers. Der.

HTTP/1.1 200 OK
Date: Sat, 08 Oct 2011 04:33:23 GMT
Server: Apache/2.2.3 (CentOS)
Content-Length: 60591Content-disposition: inline; filename="CHANGELOG.txt"
Vary: Accept-Encoding
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/plain; charset=utf-8

Ok, I'm guessing the problem is there's a newline missing between Content-Length: 60591 and Content-disposition: inline; filename="CHANGELOG.txt". Firefox 7 must just be more sensitive to it than Chrome, etc.

I know nothing about Gitweb. :( Any idea how to make that NOT do that? I love FF7 otherwise, but this makes browsing the code section nasty. :(

Assigned:Unassigned» sdboyer

I'm going to assign this to sdboyer until I can make fixes to gitweb :)

any updates?


I just found out I had this problem on my site. It only happens with firefox and not with anything else.

Any updates?

Looks like I have found the problem on:

If you go here: dmin/settings/error-reporting

Make sure you have the settings as:

Write errors to the log

and not:

Write errors to the log and to the screen

That help the issue with the error.

Took a while, but I found it.


EDIT: * This doesn't help the issue with Firefox 7 still.

Yeah, this particular problem on gitweb anyway is super easy. We need a newline between the Content-Length and Content-Disposition headers. That's it. See #2.


Thank you for your reply. I found a solution for me on my site. I currently have boost installed and an option in there was causing the problem.



So the page wouldn't load on chrome, but if I refresh it would load normally.

On firefox 7 I would get this:

"Corrupted Content error" like the picture above.

So in Boost Settings, I unchecked the : Asynchronous Operation and that fixed the isses I was having on the site.

Hope this helps someone that needs this.

Thank you,


@dmendo this has nothing to do with gitweb or the Drupal infrastructure or webchick's posted issue. If there is a bug would you please take the discussion to the boost queue or wherever is appropriate so it can be resolved effectively? No need to reply, thanks for your interest!

Priority:Normal» Major

Bumping priority.

I'm aware of this. I'm currently waiting on an upgrade path for us for gitweb, once the git repo for our path comes back online I'll look into an upgrade and if this is still a problem with the newer version.

Yeah, I've been waiting on sdboyers go ahead with a sandbox for this. I know he's pretty busy ATM though so if there's a sandbox for me to do some merge testing(and get access to the gitweb git repo again) I'll be all over it.

Title:Firefox 7-8 gives "Corrupted Content error" on any "raw" view in GitwebFirefox 7 gives "Corrupted Content error" on any "raw" view in Gitweb


After checking #2 with curl, i did two curl commands:

This one display an error in Firefox 7

< HTTP/1.1 200 OK
< Date: Thu, 10 Nov 2011 21:25:42 GMT
< Server: Apache/2.2.3 (CentOS)
< Content-Length: 3411Content-disposition: inline; filename="nodejs_solr.admin.inc"
< Vary: Accept-Encoding
< Content-Type: text/plain; charset=utf-8

This one display with no error:

< HTTP/1.1 200 OK
< Date: Thu, 10 Nov 2011 21:21:05 GMT
< Server: Apache/2.2.3 (CentOS)
< Content-Length: 3114Content-disposition: inline; filename="nodejs_solr.config.js"
< Vary: Accept-Encoding
< Content-Type: application/x-javascript

Maybe it does come from this line in the first headers:
< Content-Type: text/plain; charset=utf-8

Just to confirm Firefox 8.0 also has this problem.

Its not really a problem of identifying the problem or narrowing the causes but getting the resources to fix it.

Title:Firefox 7 gives "Corrupted Content error" on any "raw" view in GitwebFirefox 7-8 gives "Corrupted Content error" on any "raw" view in Gitweb

The path has changed from .../blob_plain/... to .../blob/... — that will work.

Yes, blob works, but it isn't great. You can't copy/paste text out of there cleanly because there are line numbers in it, nor can you download a copy of it to work with it locally without a whole lot of horsing around. :(

However, julien's observation that the second file there works fine is exactly correct. Wow, nice sleuthing. But WTF is up with that?

Anyway, probably updating to the latest Gitweb as nnewton suggests is the way to go here.

Title:Firefox 7 gives "Corrupted Content error" on any "raw" view in GitwebFirefox 7-8 gives "Corrupted Content error" on any "raw" view in Gitweb

I'm not too sure if this error happend recently or something, maybe it's due to this xss attack fix. (who maybe display the .js and .html file properly, but not the other ones, i dunno).
Another quick solution will be to upgrade to Gitphp which is like Gitweb but with few extra and syntax highlighting.

I've got the time and drive to fix this, I just need the resources... we don't have a testing environment to roll out this fix.

@neclimdul, I checked with upstream today and getting this repo back up is still a ways off. If given a repo for our version and a vendor branch for upstream do you think you could take a look at pulling some patches from upstream?

@nnewton Yessir. If you can put our branch somewhere I can access it on util I'll be set as far as that's concerned. Is there a branch warthog suggested?

I talked to sdboyer and it looks like git-dev has a lot puppet and other hacking needed to get it up and he's pretty "occupied."*groan* I'll look at setting up a VM to hack on this weekend. concerned.

It's not just Firefox :(
In my case, I was trying to click on the "Read Documentation" link in www.drupal.org/project/profiler and here's what I get:

1. Firefox 8 (mac) - content corrupted error as described above.
2. Safari 5.0.6 (mac...) - a one-line page is displayed which reads "Please check out one of the other branches"
3. Firefox 3.6.3 (Windows XP) - same one-line response - "Please check out one of the other branches"
4. IE 7 (Windows XP) (well... someone had to try it...) - same one-line response as 2 & 3.

Hopes this information assists in solving the problem.

The 'Please check out one of the other branches' message is the content of the README.txt file on the master branch for that project: http://drupalcode.org/project/profiler.git/blob/refs/heads/master:/READM...

This is telling you to look at a branch other than the master (such as 7.x-2.x: http://drupalcode.org/project/profiler.git/blob/refs/heads/7.x-2.x:/READ...) - it's not an issue with the browser but an issue that should be brought to the maintainer's attention so they can update the Documentation link.

This 'content corrupted' error therefore still only affects Firefox.

Title:Firefox 7-8 gives "Corrupted Content error" on any "raw" view in GitwebFirefox 7-9 gives "Corrupted Content error" on any "raw" view in Gitweb

FF 9.x still gives the same error.

Title:Firefox 7-9 gives "Corrupted Content error" on any "raw" view in GitwebFirefox gives "Corrupted Content error" on any "raw" view in Gitweb

Just want to make this clear. We're aware of the problem and its a high priority.

The bug is well defined and additional browser reports aren't really necessary. Thanks for your interest and feel free to click the follow button an I'll update as soon as we're able to do something.

Assigned:sdboyer» skottler
Status:Active» Needs work

I am looking at this now. I'll review with some other infra team members in a bit and then get it deployed!

Oh bless you sir!! :D

Status:Needs work» Fixed

Works for me now in Firefox 9, please test.

Status:Fixed» Active



Still gives the content error in Firefox 9.0.1 on mac.

Title:Firefox gives "Corrupted Content error" on any "raw" view in GitwebFirefox 9.0.1 Mac gives "Corrupted Content error" on any "raw" view in Gitweb

Works for me in Firefox 9.0.1 on Ubuntu 11.10. So I guess I can make use of the issue "unsubscribe" button the first time :-)

Title:Firefox 9.0.1 Mac gives "Corrupted Content error" on any "raw" view in GitwebFirefox gives "Corrupted Content error" on any "raw" view in Gitweb

also still a problem with FF 8/Debian.

Does not work on FF 9.0.1/Win either.

Title:Firefox gives "Corrupted Content error" on any "raw" view in GitwebFirefox gives "Corrupted Content error" on any "raw" or "snapshot" views in Gitweb

From FF 9.0.1 the problem also exists for snapshots, i.e. http://drupalcode.org/project/date.git/snapshot/fe24cbec478be265be01865f...

I tried it on a default gitweb all works as expected, but I do not have the d.o configuration, so not completely sure it's gitweb problem(older version on d.o?) or configuration.

We don't use the default gitweb, we use warthog9's fork with caching to support the level of traffic we have.

Snapshot downloads are still not working for me in Firefox/Ubuntu/7.0 as of today.

For instance if you go to
and click on "snapshot", it takes you to
and this gives the error reported above.

That's because the problem has still not been solved.

Assigned:skottler» Unassigned

I was going to open another issue, but I guess it's better to leave it here for now.

Some time ago when we were planning the migration, we decided to go with the warthog9 fork of gitweb.
At that time, that fork was maintained. Now it seems to not be there anymore(kernel.org), and I could not find any mention of that removal anywhere. If someone know something about that removal, please let me know.

I would say that if we are not willing to maintain warthog9 gitweb fork by ourselves(and then publish it somewhere), then IMHO it is a good time to move to another web browser interface for git. I know we have had that discussion before, but context is different now. Please notice that one of the cons mentioned on the original discussion about tizzo's drupal git viewer was maintain that code.

I started thinking about this because I wanted to try to fix this problem, but I cannot find the upstream code anywhere public, and then I have no way to start. Then, my only inference there is that we are maintaining warthog9 gitweb fork by ourselves. Am I right? (I can open another issue if requested)

Update: BTW currently versioncontrol_git(the one that provides links on project and commitlog pages) supports cgit, gitphp and gitweb. I would be happy to add support for any new if needed.

Not trying to add to the noise here. I know the overall gitweb issue is much larger, but any chance even just a temporary fix can be deployed? What happened to #31?

We were talking about this at the sprint, and sdboyer pointed out that one way of working around this might be an Apache rule to re-write the headers and stick in the missing newline. http://pastebin.com/ebPESard is a pastebin of our puppet files if someone feels so inclined.

Long-term, we want to replace gitweb with something else, since the version of gitweb we're using is an unsupported fork.

yeah, if we could just conditionally munge the headers if a raw file is being requested...would be much easier than patching our gitweb fork.

This just started working for me (using FF 14 on Linux Mint 13). Is this fixed?

works for me as well with iceweasel 12.

Status:Active» Fixed

Agreed, this appears to be fixed (I am on Firefox 13.0 on Ubuntu and previously, as recently as a couple of weeks ago, was still having this problem).

Provisionally changing the issue status, unless anyone can say that it is still broken.

Looking at the headers they seem to be still broken just not broken in a way that browsers are complaining about anymore. Good enough I guess.

I am a bit confused as to why this is fixed, I am not aware of modifications.

Status:Fixed» Active

unfixing this. Nothing was done that would have fixed this so I think this may have been just an ephemeral success :)

Status:Active» Fixed

Maybe Firefox became more tolerant. IAC it works with my FF/Win 14.0.1.

(EDIT: inadvertent status change)

changing status back to active.

Status:Fixed» Active

We may just want to change this ticket to be the "replace gitweb" ticket. Since, thats basically what it is. The FF failure itself is....almost incidental. The problem is that we have no control over your git viewer.


Ran into this via corporate software on a clients network.. Solution at end.

Here the details:

2013:02:05-05:44:50 UTM9-support-1 httpproxy[31242]: id="0003" severity="info" sys="SecureWeb" sub="http" request="0x1361cc68" function="read_response_headers" file="response.c"
line="368" message="received invalid header from server: [Content-Length: 852Content-disposition: inline; filename="no_makefile.patch"]"
2013:02:05-05:44:50 UTM9-support-1 httpproxy[31242]: id="0002" severity="info" sys="SecureWeb" sub="http" name="web request blocked" action="block" method="GET" srcip="192.168.0
.14" dstip="" user="" statuscode="502" cached="0" profile="REF_DefaultHTTPProfile (Default Proxy)" filteraction="REF_DefaultHTTPCFFAction (Default content filter act
ion)" size="2676" request="0x1361cc68" url="http://drupalcode.org/project/wysiwyg_fields.git/blob_plain/2fd8cb8f00ff22b43d16dc09f033d6ea185e98be:/no_makefile.patch" exceptions="
av,auth,content,url,ssl,mime,cache,fileextension" error="Received invalid response from Server"

Here the traffic from a TCPDUMP:


GET /project/wysiwyg_fields.git/blob_plain/2fd8cb8f00ff22b43d16dc09f033d6ea185e98be:/no_makefile.patch HTTP/1.1
Host: drupalcode.org
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:16.0) Gecko/20100101 Firefox/16.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
DNT: 1
Connection: Keep-Alive

Server response:

HTTP/1.1 200 OK
Date: Tue, 05 Feb 2013 04:44:50 GMT
Server: Apache/2.2.3 (CentOS)
Content-Length: 852Content-disposition: inline; filename="no_makefile.patch"
Vary: Accept-Encoding
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/plain; charset=utf-8
diff --git a/wysiwyg_fields.make b/wysiwyg_fields.make

The server is responding:

Content-Length: 852Content-disposition: inline; filename="no_makefile.patch"

this has to be submitted in two lines:

Content-Length: 852
Content-disposition: inline; filename="no_makefile.patch"

See as reference RFC2616 :

Assigned:Unassigned» realityloop

After discussing this with killes, sdboyer and basic' I'm now working on fixing this.

I've given realityloop access to git6staging for testing fixes.

I've just started a related issue: #1914722: Evaluate alternatives for gitweb.

Status:Active» Needs review

Fixed, info passed to sdboyer..

[realityloop@git6staging ~]$ cd /var/www/drupalcode.org/cgi-bin/lib
[realityloop@git6staging lib]$ diff cache.pl cache-fixed.pl
< print "Content-Length: $binfilesize";
> print "Content-Length: $binfilesize\n";

the change has been committed to puppet, but it seems like it hasn't been rolled out yet - have we turned off the puppet cronjob on util?

I've run puppet manually.

(Puppet had some sorta memory leak, so we switched to running it manually. http://projects.puppetlabs.com/issues/1395 is potentially the issue.)

Change appears to be present now.

Status:Needs review» Fixed

Confirmed resolved by client with the corporate firewall software

Great work on fixing a long-time issue!

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.