Hmm, you are using Swift with swauth and not Keystone eh? Have you tried using the "swift" api directly (in /apis/swift) against your endpoint?
I just looked at the Modules for Swift and Rackspace providers and they both use the OpenStackAuthenticationModule, so swauth should work just fine! /jd On Thu, Jun 27, 2013 at 9:28 AM, Ali, Saqib <docbook....@gmail.com> wrote: > Hi Andrew, > > with jClouds 1.6.0. > > works fine on Rackspace Cloud files > > And we have two internal instances of Grizzly with swauth. One has SSL the > other one doesn't. The one without SSL works. SSL one doesn't work :( > > please help > > > > > > On Thu, Jun 27, 2013 at 9:10 AM, Andrew Phillips <andr...@apache.org>wrote: > >> Am I understanding correctly that you mean that this PUT >> >> >> 07:25:05,830 DEBUG [jclouds.headers] (EJB default - 2) >> PUT >> https://swift.testing.com/**auth/testcontainer<https://swift.testing.com/auth/testcontainer>HTTP/1.1 >> 07:25:05,831 DEBUG [jclouds.headers] (EJB default - 2) >> X-Auth-Token: >> AUTH_**tk0773811843249320324443231233**53f4 >> >> should also *include* the "x-storage-url: >> >>> https://swift.testing.com/v1/**AUTH_4c0ac470-6804-4065-944b-** >>> 497efaf5d13c<https://swift.testing.com/v1/AUTH_4c0ac470-6804-4065-944b-497efaf5d13c>" >>> header that was returned by the previous response? Or that it should >>> actually try to *PUT* to that URL? >>> >> >> When you say "it works fine against Rackspace" you mean it works fine >> using jclouds (which version?) with the standard HTTP executor? Or..? >> >> What is the difference between the setup where things work vs. where the >> don't work..? >> >> Regards >> >> ap >> > >
