Amazon S3 custom error pages and enabling web hosting on bucket

Question

Hi I'll try and keep it brief, hope one of you guys knows the answer and I'm not duplicating content.

At the moment I'm using a bucket to take the strain off my server and upload large user files to amazon. This is then reserved to them when they want it via expiring URLs. When the URL expires the user is sent an XML response to say access is denied, and i want to show them a custom error page.

Here Create my own error page for Amazon S3 and Here http://docs.aws.amazon.com/AmazonS3/latest/dev/CustomErrorDocSupport.html It says you must enable web hosting on the bucket for custom error pages...

So the question is if I do this then just grant any user permissions to access just the custom error pages will this mess anything up with my current usage scenario? Or is it as simple as everything else stays the same? The docs seem vague and I dont want to mess up my current system...

Sorry if this is a noob question but everyone with the same problem in my research seems happy with the 'Enable hosting' answer and i just want to be sure...

Cheers all

Ed

Answer 1

It's not possible to combine the two things you're trying to combine: query string authentication and custom error pages.

S3 buckets can be made accessible by two different sets of endpoints, each providing a different set of front-end behaviors.

The REST endpoints provide authentication and private content (and SSL), while the Web site endpoints provide custom error (and index) documents, but the objects must be public in order to be accessible, since the web site endpoint does not support authentication (or SSL).

The differences are explained here:

http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteEndpoints.html#WebsiteRestEndpointDiff

In some environments, I use an intermediate reverse-proxy, hosted in EC2, acting as a front-end for S3 (which gives me the additional capability of rewriting portions of the request headers and capturing access logs in real-time) and I suspect this is the most viable mechanism for also providing "friendly" errors -- as my proxy does if the URL is completely missing elements like Signature= in the URL (since that can't possibly be anything but an error) but have not yet implemented anything to capture 403 Forbidden responses and style them up.

I did do some preliminary testing to add a Link: header to the error response (in the proxy), in an attempt to convince the browser to load an XSL stylesheet, but so far that has not proven viable.