Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proxy connection failure #5239

Closed
cyberduck opened this issue Sep 28, 2010 · 9 comments
Closed

Proxy connection failure #5239

cyberduck opened this issue Sep 28, 2010 · 9 comments

Comments

@cyberduck
Copy link
Collaborator

@cyberduck cyberduck commented Sep 28, 2010

6da0fcf created the issue

I have been using 3.5.1 with no issues to connect to S3. When I upgraded to 3.6.1, none of my S3 bookmarks would work, nor could I manually connect. When I try to connect, all attempts fail with an error message that reads: "I/O Error: Connection failed - Request Error." The log window shows many GET requests, but all to: "URL http://s3.amazonaws.com/ HTTP/1.1", not to the full URL of my account.

All connections were made as type 'Amazon S3', using Access Key ID for username and Secret Access Key for password. The path attempted doesn't seem to make a difference ('/' or sub paths).

Downgrading to CyberDuck 3.5.1 fixed the problem with no change to any pref files or bookmarks - all connections open and behave normally.

Transcript of log drawer from a single 3.6.1 connection attempt (auth info redacted, naturally):

GET https://s3.amazonaws.com/ HTTP/1.1
Content-Type: 
Date: Tue, 28 Sep 2010 17:23:58 GMT
Authorization: AWS <REDACTED>
User-Agent: Cyberduck/3.6.1 (6900) (Mac OS X/10.6.4) (i386)
Host: s3.amazonaws.com
Proxy-Connection: Keep-Alive

GET https://s3.amazonaws.com/ HTTP/1.1
Content-Type: 
User-Agent: Cyberduck/3.6.1 (6900) (Mac OS X/10.6.4) (i386)
Proxy-Connection: Keep-Alive
Date: Tue, 28 Sep 2010 17:23:58 GMT
Authorization: AWS <REDACTED>
Host: s3.amazonaws.com

GET https://s3.amazonaws.com/ HTTP/1.1
Content-Type: 
User-Agent: Cyberduck/3.6.1 (6900) (Mac OS X/10.6.4) (i386)
Proxy-Connection: Keep-Alive
Date: Tue, 28 Sep 2010 17:23:58 GMT
Authorization: AWS <REDACTED>
Host: s3.amazonaws.com

GET https://s3.amazonaws.com/ HTTP/1.1
Content-Type: 
User-Agent: Cyberduck/3.6.1 (6900) (Mac OS X/10.6.4) (i386)
Proxy-Connection: Keep-Alive
Date: Tue, 28 Sep 2010 17:23:58 GMT
Authorization: AWS <REDACTED>
Host: s3.amazonaws.com

GET https://s3.amazonaws.com/ HTTP/1.1
Content-Type: 
User-Agent: Cyberduck/3.6.1 (6900) (Mac OS X/10.6.4) (i386)
Proxy-Connection: Keep-Alive
Date: Tue, 28 Sep 2010 17:23:59 GMT
Authorization: AWS <REDACTED>
Host: s3.amazonaws.com

GET https://s3.amazonaws.com/ HTTP/1.1
Content-Type: 
User-Agent: Cyberduck/3.6.1 (6900) (Mac OS X/10.6.4) (i386)
Proxy-Connection: Keep-Alive
Date: Tue, 28 Sep 2010 17:23:59 GMT
Authorization: AWS <REDACTED>
Host: s3.amazonaws.com
@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Sep 30, 2010

@dkocher commented

It looks like you have set https://s3.amazonaws.com/ in the Path setting of the bookmark. Better leave that blank or change it to a existing bucket and/or directory.

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Sep 30, 2010

6da0fcf commented

I haven't set that in the Path setting of the bookmark. It's in the 'Web URL' setting, but I can't change it, I presume it's been placed there by the fact of selecting S3 as the connection type. I've included a screenshot which shows the bookmark edit window open to the bookmark which is failing to load. I've redacted the bits of the image that contained AWS user data, hence the cutout bars.

external image

The bookmark visible "Development-S3-OSX" has a path of "/medidata-osx". That doesn't work either, and fails in the same manner with the same attempted connections and errors. It looks like it's ignoring the path, or something like that. I'll try to get a screenshot of that:

external image

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Oct 1, 2010

@dkocher commented

This is strange and I can't reproduce. Can you try if you still have the issue when using the latest snapshot build from (http://update.cyberduck.ch/nightly/).

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Oct 1, 2010

6da0fcf commented

Downloaded build 7154 and tried. Exact same behavior. None of the requests in the transcript have anything other than the base path in them:

GET https://s3.amazonaws.com/ HTTP/1.1

...no matter what path the bookmark (or manual connection window) has. The 'URL' field in the connection window reports:

https://@s3.amazonaws.com:443/ (or whatever path I have in the 'path' field)

...but that doesn't seem to be what's being requested.

One add'l point - I am behind a Bluecoat proxy (although I think they've configured it to allow direct access to S3). I'm not sure that's relevant, since as I said it seems to work fine with 3.5.1.

Hm, I realized I should probably include a transcript of a successful 3.5.1 connection. Here it is:

---cut---

CONNECT s3.amazonaws.com:443 HTTP/1.1
User-Agent: Cyberduck/3.5.1 (6117) (Mac OS X/10.6.4) (i386)[\r][\n]
Host: s3.amazonaws.com[\r][\n]
Proxy-Connection: Keep-Alive[\r][\n]
[\r][\n]
HTTP/1.1 200 Connection established[\r][\n]
HTTP/1.1 200 Connection established[\r][\n]
[\r][\n]
GET / HTTP/1.1[\r][\n]
Content-Type: [\r][\n]
Date: Fri, 01 Oct 2010 19:52:49 GMT[\r][\n]
Authorization: AWS <REDACTED>[\r][\n]
User-Agent: Cyberduck/3.5.1 (6117) (Mac OS X/10.6.4) (i386)[\r][\n]
Host: s3.amazonaws.com[\r][\n]
[\r][\n]
HTTP/1.1 200 OK[\r][\n]
HTTP/1.1 200 OK[\r][\n]
x-amz-id-2: tG5+CvdUnkrjv2xK+QnFXtyKV+2gYo4ivtJdGeFD77550uo+fgGwThjWp7ASqsnq[\r][\n]
x-amz-request-id: 0EC1E33B1E7334E8[\r][\n]
Date: Fri, 01 Oct 2010 19:52:50 GMT[\r][\n]
Content-Type: application/xml[\r][\n]
Transfer-Encoding: chunked[\r][\n]
Server: AmazonS3[\r][\n]
[\r][\n]
[\r][\n]
GET / HTTP/1.1[\r][\n]
Content-Type: [\r][\n]
Date: Fri, 01 Oct 2010 19:52:49 GMT[\r][\n]
Authorization: AWS <REDACTED>[\r][\n]
User-Agent: Cyberduck/3.5.1 (6117) (Mac OS X/10.6.4) (i386)[\r][\n]
Host: s3.amazonaws.com[\r][\n]
[\r][\n]
HTTP/1.1 200 OK[\r][\n]
HTTP/1.1 200 OK[\r][\n]
x-amz-id-2: 6oqPIh7BKAfimjyCVigGBOMUigupW+cEphpYgPiqn3eoqbhsbGwYreHM3ikaYSQv[\r][\n]
x-amz-request-id: 3501AEA7462646B3[\r][\n]
Date: Fri, 01 Oct 2010 19:52:50 GMT[\r][\n]
Content-Type: application/xml[\r][\n]
Transfer-Encoding: chunked[\r][\n]
Server: AmazonS3[\r][\n]
[\r][\n]
[\r][\n]

---cut---

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Oct 2, 2010

@dkocher commented

Replying to [comment:8 https://www.google.com/accounts/o8/id?id=aitoawnuslsj0omptnilptbjmoouhffiiyi1z-u]:

One add'l point - I am behind a Bluecoat proxy (although I think they've configured it to allow direct access to S3). I'm not sure that's relevant, since as I said it seems to work fine with 3.5.1.

Thanks for the additional information. I can replicate the issue now with a proxy setup.

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Oct 2, 2010

@dkocher commented

As a workaround you can use a HTTP connection without SSL until this issue is resolved.

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Oct 2, 2010

@dkocher commented

Bug was introduced in e9a272a because the secure socket factory no more implements org.apache.commons.httpclient.protocol.org.apache.commons.httpclient.protocol. Then the socket is assumed not secure and no CONNECT for a secure tunnel is sent to the proxy.

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Oct 2, 2010

@dkocher commented

In 07afcd0.

Loading

@cyberduck cyberduck closed this Oct 2, 2010
@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Oct 4, 2010

6da0fcf commented

Just to confirm: works for me now in build 7192. Many thanks.

Loading

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants