When attempting to create or update Cache Group fallbacks, it is mandated that both the Cache Group(s) in question and it's proposed fallback(s) be of type EDGE_LOC in order for the relationship to be successfully created/updated. However, if this is not the case, the endpoint will log an error to the server's internal logs, but then return a success to the client - despite the request not actually resulting in a success.
Here's an example where a client attempts to modify an existing fallback relationship to instead have an EDGE_LOC Cache Group fall back on a MID_LOC Cache Group:
The Request:
PUT /api/1.1/cachegroup_fallbacks HTTP/1.1
Host: trafficops.infra.ciab.test
User-Agent: curl/7.47.0
Accept: */*
Cookie: mojolicious=...
Content-Length: 59
Content-Type: application/x-www-form-urlencoded
[{"cacheGroupId": 11, "fallbackId": 6, "fallbackOrder": 1}]The response
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept
Access-Control-Allow-Methods: POST,GET,OPTIONS,PUT,DELETE
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Content-Type: application/json
Date: Thu, 08 Nov 2018 15:07:06 GMT
Server: Mojolicious (Perl)
Set-Cookie: mojolicious=...; expires=Thu, 08 Nov 2018 19:07:06 GMT; path=/; HttpOnly
Vary: Accept-Encoding
Whole-Content-Sha512: 7QQpwDEmSpSPn6E3FAjxNw3E7xKP3TOBdnvZiBHQwOLmOH6Eiaq58f3eMPYAuK4qMSAKBj9Y2R//Fpa59YCMRw==
Content-Length: 225
{ "alerts": [
{
"level": "success",
"text": "Backup configuration UPDATE for cache group 11 successful."
}
],
"response": [
{
"cacheGroupId": 11,
"fallbackName": "CDN_in_a_Box_Edge",
"fallbackOrder": 1,
"fallbackId": 7,
"cacheGroupName": "test"
}
]}(Content-Length incorrect to allow for more readable formatting of the payload)
Note that the response indicates that the fallback Cache Group is the one identified by 7 - which is the Cache Group that was already assigned as the fallback prior to this PUT request - and NOT the Cache Group identified by 6 as per the request payload.
The proper response for attempting to perform an invalid option would likely be a 400 BAD REQUEST, optionally with an associated alerts object describing the error.
When attempting to create or update Cache Group fallbacks, it is mandated that both the Cache Group(s) in question and it's proposed fallback(s) be of type
EDGE_LOCin order for the relationship to be successfully created/updated. However, if this is not the case, the endpoint will log an error to the server's internal logs, but then return a success to the client - despite the request not actually resulting in a success.Here's an example where a client attempts to modify an existing fallback relationship to instead have an
EDGE_LOCCache Group fall back on aMID_LOCCache Group:The Request:
The response
(Content-Length incorrect to allow for more readable formatting of the payload)
Note that the response indicates that the fallback Cache Group is the one identified by
7- which is the Cache Group that was already assigned as the fallback prior to thisPUTrequest - and NOT the Cache Group identified by6as per the request payload.The proper response for attempting to perform an invalid option would likely be a
400 BAD REQUEST, optionally with an associatedalertsobject describing the error.