Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 358043

Summary:	Smart HTTP detection fails if media types are defined
Product:	[Technology] JGit	Reporter:	Don Brown <mrdon>
Component:	JGit	Assignee:	Project Inbox <jgit.core-inbox>
Status:	NEW ---	QA Contact:
Severity:	normal
Priority:	P3	CC:	alan.mcgovern, ben.heiskell, dmitry.neverov, sop
Version:	1.0
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Don Brown

2011-09-18 23:36:25 EDT

The Content-Type header can have media types defined as specified here:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.17

Unfortunately, jgit matches the content type with "equals()" rather than something more permissive like "contains()".  This causes Smart HTTP to not be able to be detected on any server that adds a media type to the value.

I've worked around this by forking TransportHttp (and a host of package private classes necessary to get it to compile), then switching the two instances of equals() for contains().

Comment 1 Dmitry Neverov

2011-12-26 02:55:25 EST

Jgit fails to clone repository from appharbor.com, because appharbor responds with following header:

Content-Type: application/x-git-upload-pack-advertisement; charset=utf-8

It seems like native git doesn't check Content-Type header of response, and it clones without errors.

Could you please review a following fix: http://egit.eclipse.org/r/#change,4878

Comment 2 Shawn Pearce

2012-07-04 17:36:40 EDT

*** Bug 384289 has been marked as a duplicate of this bug. ***

Comment 3 Shawn Pearce

2012-07-04 17:39:56 EDT

The appharbor.com server contains a bug in its protocol support. The server is *not* supposed to be including a charset in the Content-Type. The application/x-git-* MIME types do not recognize a charset parameter on the type.

What does Content-Type: image/png; charset=UTF-8 mean? Its a non-sensical content type. You don't need a charset supplied with a PNG MIME type. Likewise the Git MIME type does not support a charset.

Comment 4 Alan McGovern

2012-07-05 06:30:04 EDT

While I do agree that appharbor is broken in this case, it would still be awesome if JGit parsed the header according to the specification. The header appharbor sends is syntactically correct so by parsing and ignoring (or logging?) the erroneous charset information jgit would be able to work with this and all other buggy servers.

As such, would a fix similar to that proposed in #384289 be acceptable? It's a trivial change which would improve things in a very tangible way for JGit users.

Comment 5 Ben Heiskell

2013-02-05 09:29:21 EST

Adding that this issue also affects RhodeCode[1], and that the patch[2] addresses the issue.

[1] http://rhodecode.org/
[2] https://git.eclipse.org/r/#/c/4878/

Comment 6 Ben Heiskell

2013-02-05 09:58:26 EST

Clarification, it affects RhodeCode versions prior to 1.4.3 [0]. I didn't realize the instance I was testing against was running old code. Noting this in case anyone else runs into the same problem.

[0] https://bitbucket.org/marcinkuzminski/rhodecode/issue/591/