Request redirection and the REST API
This section describes how to handle HTTP redirects by using the Amazon S3 REST API. For general information about Amazon S3 redirects, see Making requests in the Amazon Simple Storage Service API Reference.
Redirects and HTTP user-agents
Programs that use the Amazon S3 REST API should handle redirects either at the application layer or the HTTP layer. Many HTTP client libraries and user agents can be configured to correctly handle redirects automatically; however, many others have incorrect or incomplete redirect implementations.
Before you rely on a library to fulfill the redirect requirement, test the following cases:
-
Verify all HTTP request headers are correctly included in the redirected request (the second request after receiving a redirect) including HTTP standards such as Authorization and Date.
-
Verify non-GET redirects, such as PUT and DELETE, work correctly.
-
Verify large PUT requests follow redirects correctly.
-
Verify PUT requests follow redirects correctly if the 100-continue response takes a long time to arrive.
HTTP user-agents that strictly conform to RFC 2616 might require explicit confirmation before following a redirect when the HTTP request method is not GET or HEAD. It is generally safe to follow redirects generated by Amazon S3 automatically, as the system will issue redirects only to hosts within the amazonaws.com.cn domain and the effect of the redirected request will be the same as that of the original request.
Redirects and 100-Continue
To simplify redirect handling, improve efficiencies, and avoid the costs associated
with sending a redirected request body twice, configure your application to use
100-continues for PUT operations. When your application uses 100-continue, it does not
send the request body until it receives an acknowledgement. If the message is rejected
based on the headers, the body of the message is not sent. For more information about
100-continue, go to RFC 2616
Section 8.2.3
Note
According to RFC 2616, when using Expect: Continue with an unknown
HTTP server, you should not wait an indefinite period before sending the request
body. This is because some HTTP servers do not recognize 100-continue. However, Amazon S3
does recognize if your request contains an Expect: Continue and will
respond with a provisional 100-continue status or a final status code. Additionally,
no redirect error will occur after receiving the provisional 100 continue go-ahead.
This will help you avoid receiving a redirect response while you are still writing
the request body.
Redirect example
This section provides an example of client-server interaction using HTTP redirects and 100-continue.
Following is a sample PUT to the quotes.s3.amazonaws.com.cn bucket.
PUT /nelson.txt HTTP/1.1 Host: quotes.s3.amazonaws.com Date: Mon, 15 Oct 2007 22:18:46 +0000 Content-Length: 6 Expect: 100-continue
Amazon S3 returns the following:
HTTP/1.1 307 Temporary Redirect Location: http://quotes.s3-4c25d83b.amazonaws.com.cn/nelson.txt?rk=8d47490b Content-Type: application/xml Transfer-Encoding: chunked Date: Mon, 15 Oct 2007 22:18:46 GMT Server: AmazonS3 <?xml version="1.0" encoding="UTF-8"?> <Error> <Code>TemporaryRedirect</Code> <Message>Please re-send this request to the specified temporary endpoint. Continue to use the original request endpoint for future requests. </Message> <Endpoint>quotes.s3-4c25d83b.amazonaws.com.cn</Endpoint> <Bucket>quotes</Bucket> </Error>
The client follows the redirect response and issues a new request to the
quotes.s3-4c25d83b.amazonaws.com.cn temporary endpoint.
PUT /nelson.txt?rk=8d47490b HTTP/1.1 Host: quotes.s3-4c25d83b.amazonaws.com.cn Date: Mon, 15 Oct 2007 22:18:46 +0000 Content-Length: 6 Expect: 100-continue
Amazon S3 returns a 100-continue indicating the client should proceed with sending the request body.
HTTP/1.1 100 Continue
The client sends the request body.
ha ha\n
Amazon S3 returns the final response.
HTTP/1.1 200 OK Date: Mon, 15 Oct 2007 22:18:48 GMT ETag: "a2c8d6b872054293afd41061e93bc289" Content-Length: 0 Server: AmazonS3