Community
Participate
Working Groups
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().
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
*** Bug 384289 has been marked as a duplicate of this bug. ***
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.
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.
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/
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/
