[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jgit-dev] Fwd: Protocol Understanding

I opened a case in AWS minutes prior to filing this email, but I wanted to be clear on all sides.

My concern was about what would tell if it was mandatory, but havingÂa prior issue like w/ Github is a good call. That will make the argument easier

Thanks!


--
-- Aldrin Leal, <aldrin@xxxxxxxxxxx> / http://meadiciona.com/aldrinleal


On Thu, Nov 29, 2012 at 12:22 PM, Shawn Pearce <spearce@xxxxxxxxxxx> wrote:
On Thu, Nov 29, 2012 at 4:20 AM, Aldrin Leal <aldrin@xxxxxxxxxxx> wrote:
> 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
> publishing
>
> 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:
>
> https://gist.github.com/4a320df5326aa2d91df0

From this trace AWS is using a very bare response:

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

> Now the real questions:
>
> a. Are those content-types mandatory?

To JGit, yes, to CGit no, but I now wish I had found a way to get that
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.

> b. Are there any circunventing options?

No, not in JGit. This has happened before, e.g. GitHub first deployed
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.

> (btw, the culprit is at
> https://bitbucket.org/aldrinleal/beanstalker/src/4a1d99cc560cde3957a6140cad802efbc22a88a3/beanstalk-maven-plugin/src/main/java/br/com/ingenieux/mojo/beanstalk/bundle/FastDeployMojo.java
> - Don't comment my Porcelain API Skills - I know its awful, to saw the least
> - But this is worth another couple of emails)

I would try telling AWS they are doing it wrong. But I don't know how
good their customer support is compared to e.g. GitHub... who also now
has a JGit developer on staff.