Closed Bug 1558751 Opened 7 years ago Closed 6 years ago

CloudFront should not respond with HTML 403 errors

Categories

(Cloud Services :: Server: Remote Settings, defect)

Product:
Cloud Services
Component:
Server: Remote Settings
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: leplatrem, Assigned: wezhou)

References

Details

In Bug 1558709 we noticed that CloudFront returned 403 HTML responses on write operations. (error is This distribution is not configured to allow the HTTP request method that was used for this request)

For example, this is fine on the source:

http POST https://settings.prod.mozaws.net/v1/buckets/security-state/collections/intermediate/records                                                
HTTP/1.1 405 Method Not Allowed
{
    "code": 405,
    "errno": 115,
    "error": "Method Not Allowed",
    "message": "Method not allowed on this endpoint."
}

But wrong via CloudFront:

http POST https://firefox.settings.services.mozilla.com/v1/buckets/security-state/collections/intermediate/records
HTTP/1.1 403 Forbidden
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD><BODY>
<H1>403 ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
This distribution is not configured to allow the HTTP request method that was used for this request. The distribution supports only cachable requests.

<BR clear="all">
<HR noshade size="1px">
<PRE>
Generated by cloudfront (CloudFront)
Request ID: -gPnhMlrZUC6eZNhhe8npiN3G0DhO3WMdSiQbGSBaIx0tSptRr94lg==
</PRE>
<ADDRESS>
</ADDRESS>
</BODY></HTML>

Do you think it's possible to change that? Seeing the error message The distribution supports only cachable requests. I'm not sure, but if it's trivial maybe we'd want to just return what the source returns...
Thanks!

I see two options here:

  1. We can allow POST (and maybe PUT, PATCH and DELETE) requests through CloudFront, and they will hit our origin server. I don't have any metrics on how many of these requests we have, though, so we'd need to look into that first to avoid overloading the servers, since those requests can't be cached by CloudFront and it'd just act as a proxy

  2. We can customize the error page for HTTP 403 on CloudFront and make it return JSON instead.

I don't think it makes too much sense to let go through write operations since they will all return the same response 405 Method Not Allowed.

{
    "code": 405,
    "errno": 115,
    "error": "Method Not Allowed",
    "message": "Method not allowed on this endpoint."
}

Option 2. would be prefered here.

If the response has to be a 403, then it should look like this instead:

{
    "code": 403,
    "errno": 121,
    "error": "Forbidden",
    "message": "This user is not allowed to perform this operation"
}

Wei, apparently it is possible to configure 403/405 responses to be static JSON instead of HTML (which makes our clients fail with parsing instead of proper sync error).

Do you think we can do it? Is it trivial? Otherwise, please close this ticket with a «Won't Fix», it's low priority.

Assignee: autrilla → wezhou
Flags: needinfo?(wezhou)

Mathieu, first I agree that we should open up write access only for the purpose of being able to serving a nicer json object instead of html file.

Suppose we don't open up the write permission, how do we "configure 403/405 responses to be static JSON instead of HTML"? I'm not aware that we can do that. Could you send me a link to the doc for me to take a look?

Then we'll see if it's trivial or not.

Thanks.

Flags: needinfo?(wezhou)

Mathieu, first I agree that we should open up write access only for the purpose of being able to serving a nicer json object instead of html file.

I guess you mean «we should not»

Could you send me a link to the doc for me to take a look?

Adrian mentions it in Comment 1. I found this https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesErrorPages

I guess you mean «we should not»

Yes, that's what I meant. Sorry about the confusion. :)

Adrian mentions it in Comment 1. I found this https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesErrorPages

Unfortunately, doing that requires allowing POST, PUT and other methods first, afaik.

Unfortunately, doing that requires allowing POST, PUT and other methods first, afaik.

Let's leave the current behavior. Clients trying to POST will fail anyway.

Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.