/deliveryservices/{{ID}}/safe returns incorrect response for the requested API version #5891
Assignees
Labels
regression bug
a bug in existing functionality introduced by a new version
Traffic Ops
related to Traffic Ops
Comments
ocket8888
added
bug
ocket8888
added
regression bug
|
Actually, this has to be a regression. The released 1.5, 2.0, and 3.0 APIs could not possibly have been returning data that didn't exist in the database until 3.1. |
ocket8888
added a commit
to ocket8888/trafficcontrol
that referenced
this issue
Jul 8, 2021
Previously, it would return APIv3.1 structures for API version 1.5, 2.0, 3.0, 3.1, and 4.0 (as well as unrecognized versions). It now returns the appropriate version structures for each requested version. This fixes apache#5891
rawlinp
pushed a commit
that referenced
this issue
Jul 8, 2021
* Add migration for DS TLS versions
* Update DS model in APIv4
* Add TLSVersions handling and validation for invalid versions to /deliveryservices
* Fix incorrect responses from /deliveryservices/{ID}/safe
Previously, it would return APIv3.1 structures for API version 1.5, 2.0,
3.0, 3.1, and 4.0 (as well as unrecognized versions). It now returns the
appropriate version structures for each requested version.
This fixes #5891
* Fix DSRs storing/returning APIv4 DSes with empty tlsVersions instead of null
* Fix being unable to update DSes with no TLS versions
* Add ATC "known" TLS versions and a warning generation function for possibly insecure version sets
* Add tlsVersions warnings to /deliveryservices
* Add validation that prevents tlsVersions on STEERING/CLIENT_STEERING delivery services
* Fix a bug where adding TLS versions returns a 500 ISE response
* Fix indirection of non-pointer value
* Add TLS versions tests to the v4 API client
* Remove 'lastUpdated' timestamps from testing data
This breaks parsing when the API endpoints that use this data change
from our custom format to RFC3339.
* Update /deliveryservices documentation
* Update /deliveryservices/{{ID}} documentation
* Update /deliveryservices/{{ID}}/safe documentation
* Update /deliveryservice_requests documentation
* Update /deliveryservice_requests/{{ID}}/status documentation
* Update /deliveryservice_requests/{{ID}}/assign documentation
* Update /servers/{{ID}}/deliveryservices documentation
* Add section about TLS versions to the Delivery Service overview docs
* Updated CHANGELOG
* Revert non-nullable DS fields
* Change version checking to proper upgrade to preserve existing pattern
* Rename function to make its purpose clear
* Move comment into GoDoc where it's more useful
* Use Exec for queries that don't return rows
* Consolidate TLS Versions warnings into a single function
That function is now a method of a Delivery Service, which means the
call signatures of various functions in the
github.com/apache/trafficcontrol/traffic_ops/traffic_ops_golang/deliveryservice
package no longer need to be changed.
* re-use query for TLS Versions
* Fix tests for new query structure
* Revert all breaking DS changes
* Fix not saving DS changes
* Fix unit test failure
* Fix integration test missing required DS fields
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm submitting a ...
Traffic Control components affected ...
Current behavior:
Making a PUT request to
/deliveryservices/{{ID}}/safewill return a different structure from a request made to/deliveryservicesfor the same API version. As these are not the same endpoint, there's technically no reason they need to return the same structural representation for the same Delivery Service at the same API version, but because released API versions were retroactively changed to return extra fields, this is a regression bug. In fixing it, I suggest we define the response structure to be isomorphic to/deliveryservices.The various API versions requested for
/deliveryservices/{{ID}}/safecompared to the API version of/deliveryservicesthat would yield the same structure as/deliveryservices/{{ID}}/safeare given below:/deliveryservices/{{ID}}/safeversion/deliveryservicesversionExpected behavior:
The structure of a response from
/deliveryservices/{{ID}}/safeshould be the same as that of a response from/deliveryservicesfor the same API version. In other words, instead of the behavior described by the above table, what I'd expect to see is something more like:/deliveryservices/{{ID}}/safeversion/deliveryservicesversionMinimal reproduction of the problem with instructions:
Make requests to
/deliveryservices/{{ID}}/safe, note the presence or absence of fields introduced or removed in various API versions of/deliveryservicesand their presence or absence from/deliveryservices/{{ID}}/safe.The text was updated successfully, but these errors were encountered: