|Re: [jgit-dev] Fwd: Protocol Understanding|
On Thu, Nov 29, 2012 at 4:20 AM, Aldrin Leal <aldrin@xxxxxxxxxxx> wrote:From this trace AWS is using a very bare response:
> Beyond S3, Elastic Beanstalk also allows users to publish to it via Git,
> using a proprietary extension (not documented in the AWS Docs). By looking
> at some sources, basically, it seems AWS Exposes a Custom Endpoint for
> Using the canonical git, it works, but when using jgit, it throws an
> exception due to a wrong content type. Other than that, it actually works
> (as a new application version is thrown)
> I attached some wire logs from Java into this URL:
Â HTTP/1.1 200 OK
Â Transfer-Encoding: chunked
Â Date: Thu, 29 Nov 2012 09:01:52 GMT
Â Server: AWS
Â ...git data...
At least they managed to cram "Server: AWS" into the response and a
"Date" header. Too bad they can't afford the bytes required to tell
the client what content it is parsing. Are Date and Server required by
HTTP standards, while Content-Type is optional when a payload is
To JGit, yes, to CGit no, but I now wish I had found a way to get that
> Now the real questions:
> a. Are those content-types mandatory?
Content-Type header from libcurl and checked it when I added smart
HTTP support to CGit back in 1.6.6. I really didn't want the client
parsing random crap that might come back from a POST. Unfortunately
the way libcurl is wrapped and used in CGit I didn't have easy access
to the Content-Type response header, so I punted and just assumed
whatever was being returned was okey dokey.
No, not in JGit. This has happened before, e.g. GitHub first deployed
> b. Are there any circunventing options?
their own HTTP interface and didn't bother to test with JGit either.
Not until users/customers complained and pointed out they weren't
compatible with the CGit implementation.
I would try telling AWS they are doing it wrong. But I don't know how
> (btw, the culprit is at
> - Don't comment my Porcelain API Skills - I know its awful, to saw the least
> - But this is worth another couple of emails)
good their customer support is compared to e.g. GitHub... who also now
has a JGit developer on staff.