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.

Comments

webchick’s picture

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.

webchick’s picture

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. :(

neclimdul’s picture

Assigned:Unassigned» sdboyer

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

BeaPower’s picture

any updates?

dmendo11’s picture

Hi,

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

Any updates?

dmendo11’s picture

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.

David

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

webchick’s picture

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.

dmendo11’s picture

Webchick,

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.

On GOOGLE CHROME I WAS GETTING AN ERROR LIKE THIS

Error 346 (net::ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_LENGTH): Unknown error.:

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,

David

neclimdul’s picture

@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!

choster’s picture

webchick’s picture

Priority:Normal» Major

Bumping priority.

nnewton’s picture

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.

neclimdul’s picture

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.

julien’s picture

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

Hi,

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

webchick’s picture

Just to confirm Firefox 8.0 also has this problem.

neclimdul’s picture

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

roball’s picture

Title:Firefox 7 gives "Corrupted Content error" on any "raw" view in Gitweb» Firefox 7-8 gives "Corrupted Content error" on any "raw" view in Gitweb
salvis’s picture

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

webchick’s picture

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.

julien’s picture

Title:Firefox 7 gives "Corrupted Content error" on any "raw" view in Gitweb» Firefox 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).
http://seclists.org/oss-sec/2011/q2/539
http://kerneltrap.org/mailarchive/git/2008/5/31/1991164/thread
Another quick solution will be to upgrade to Gitphp which is like Gitweb but with few extra and syntax highlighting.
www.xiphux.com/programming/gitphp/

neclimdul’s picture

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.

nnewton’s picture

@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?

neclimdul’s picture

@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.

BWPanda’s picture

petey318’s picture

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.

BWPanda’s picture

@petey318
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.

rfay’s picture

roball’s picture

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

FF 9.x still gives the same error.

neclimdul’s picture

Title:Firefox 7-9 gives "Corrupted Content error" on any "raw" view in Gitweb» Firefox 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.

skottler’s picture

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!

webchick’s picture

Oh bless you sir!! :D

klausi’s picture

Status:Needs work» Fixed

Works for me now in Firefox 9, please test.

webchick’s picture

Status:Fixed» Active

Nope.

http://drupalcode.org/project/drupal.git/blob_plain/e4eae7e7ad5eb989dd2d...

Still gives the content error in Firefox 9.0.1 on mac.

klausi’s picture

Title:Firefox gives "Corrupted Content error" on any "raw" view in Gitweb» Firefox 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 :-)

Gerhard Killesreiter’s picture

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

also still a problem with FF 8/Debian.

salvis’s picture

Does not work on FF 9.0.1/Win either.

marvil07’s picture

Title:Firefox gives "Corrupted Content error" on any "raw" view in Gitweb» Firefox 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 1.7.8.3-1 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.

neclimdul’s picture

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

jhodgdon’s picture

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

For instance if you go to
http://drupalcode.org/project/api.git/tree/refs/heads/6.x-1.x
and click on "snapshot", it takes you to
drupalcode.org/project/api.git/snapshot/refs/heads/6.x-1.x.tar.gz
and this gives the error reported above.

roball’s picture

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

marvil07’s picture

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.

markcarver’s picture

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?

webchick’s picture

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.

sdboyer’s picture

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.

BWPanda’s picture

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

killes@www.drop.org’s picture

works for me as well with iceweasel 12.

jhodgdon’s picture

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.

neclimdul’s picture

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.

killes@www.drop.org’s picture

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

nnewton’s picture

Status:Fixed» Active

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

salvis’s picture

Status:Active» Fixed

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

(EDIT: inadvertent status change)

killes@www.drop.org’s picture

changing status back to active.

nnewton’s picture

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.

-N

realityloop’s picture

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="140.211.10.6" 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:

Browser:

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 :
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13
and
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2

realityloop’s picture

Assigned:Unassigned» realityloop

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

basic’s picture

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

marvil07’s picture

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

realityloop’s picture

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
478c478
< print "Content-Length: $binfilesize";
---
> print "Content-Length: $binfilesize\n";
sdboyer’s picture

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?

killes@www.drop.org’s picture

I've run puppet manually.

drumm’s picture

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

realityloop’s picture

Change appears to be present now.

realityloop’s picture

Status:Needs review» Fixed

Confirmed resolved by client with the corporate firewall software

skottler’s picture

Great work on fixing a long-time issue!

Status:Fixed» Closed (fixed)

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

Component:drupalcode.org» Git