Firefox gives "Corrupted Content error" on any "raw" or "snapshot" views in Gitweb

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

any updates?

Hi,

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.

David

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

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

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

Marked as duplicates:
#1310530: Repository Viewer snapshots are broken
#1323592: git repository viewer's 'raw' links are broken

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.

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

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

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

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/

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.

Duplicate: #1343132: Installation Document Corrupted Content Error

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.

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

Marked #1358164: Repository viewer tarball generation broken "Corrupted Content Error" as a duplicate

FF 9.x still gives the same error.

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.

More duplicates:
#1106858: Read documentation not working
#1371374: 'Read Documentation' link on project page is wrong
#1387886: Gitweb blob_plain view broken on some browsers

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

Works for me now in Firefox 9, please test.

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 :-)

also still a problem with FF 8/Debian.

Does not work on FF 9.0.1/Win either.

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.

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

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

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?

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.

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.

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

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

(EDIT: inadvertent status change)

changing status back to 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

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

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.

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";

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.

Confirmed resolved by client with the corporate firewall software

Great work on fixing a long-time issue!