Hello Jeremy, We tested with curl and it works fine.
The question why does it work with the proxy end points, but not when we add the Apache web front? Thanks, On Thu, Jun 27, 2013 at 10:29 AM, Jeremy Daggett <jeremy.dagg...@gmail.com>wrote: > 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 >>> >> >> >
