path style public_url for AWS caused permanent direct #285

Closed
ashchan opened this Issue Apr 19, 2011 · 3 comments

Comments

Projects
None yet
2 participants

ashchan commented Apr 19, 2011

The public_url for AWS uses the path style, which generates url like this:

https://s3.amazonaws.com/bucketname/a/file.ext

I have a bucket located in the ap-northeast-1 region (Tokyo). When visiting the public url, AWS returns an XML error document:

<?xml version="1.0" encoding="UTF-8"?> 
<Error>
    <Code>PermanentRedirect</Code>
    <Message>The bucket you are attempting to access must be addressed using the specified endpoint. Please send all future requests to this endpoint.</Message>
    <RequestId>B36E38A3735DB0D9</RequestId>
    <Bucket>bucketname</Bucket>
    <HostId>zRMkxTCnbhL9wGLrGuF7PL+4/skiMMHfeW99QVMPdZVMxQCS0dYoUqgOcAECTX5j</HostId>
    <Endpoint>bucketname.s3.amazonaws.com</Endpoint>
</Error>

And here's curl results of both the subdomain style and path style urls:

$ curl -I https://bucketname.s3.amazonaws.com/a/file.ext
HTTP/1.1 200 OK
x-amz-id-2: YP55YHqTsYOfW8glu2fM7e+UOO7CH4EC1/vG6yAvyXF26DmaiqtEWoDvXc0bcLBs
x-amz-request-id: 6F743E9E1A9E6CBB
Date: Tue, 19 Apr 2011 01:25:44 GMT
Cache-Control: max-age=315576000
Last-Modified: Mon, 18 Apr 2011 03:38:50 GMT
ETag: "cef94523a777b370d1da3f27eaf83f35"
Accept-Ranges: bytes
Content-Type: binary/octet-stream
Content-Length: 193504
Server: AmazonS3

$ curl -I https://s3.amazonaws.com/bucketname/a/file.ext
HTTP/1.1 301 Moved Permanently
x-amz-request-id: D21D588F7B42F6B0
x-amz-id-2: IYvK0qdE6sPRgZMyOU+f0cQr+JHV6y7b8falWyAcsYu9jLFvbCUOR3QCe3hsSUZP
Content-Type: application/xml
Transfer-Encoding: chunked
Date: Tue, 19 Apr 2011 01:26:12 GMT
Server: AmazonS3

The path style url returns 301 without a Location value.

Note: bucketname is not the actual bucket name in use.

ashchan commented Apr 19, 2011

For a bucket not in the US Standard region, it seems we have to use the subdomain style.

Contributor

geemus commented Apr 19, 2011

That is unfortunate, I guess this means that buckets outside US Standard that have subdomain-incompatible names are just not accessible from public urls? That would be unfortunate. In any event I have some logic we can add in from fog that will figure out whether something is subdomain compatible and use that if it can. I'll work on integrating that presently. Thanks for the detailed bug report, makes getting it fixed much, much easier.

@geemus geemus closed this in e691843 Apr 19, 2011

ashchan commented Apr 20, 2011

Thanks for the quick fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment