Created attachment 11133 [details] Script to reproduce Due to a cache issue you can get a 404 for roles even if the role is correct: ``` Could not find object of type 'role' with URL 'http://primary.school.test/ucsschool/kelvin/v1/roles/teacher'. ``` `request.url_for` uses the `HOST` header from the request to calculate an absolute url which we cache. https://git.knut.univention.de/univention/components/ucsschool-kelvin-rest-api/-/blob/main/kelvin-api/ucsschool/kelvin/urls.py?ref_type=heads#L50 Our cache key is missing the `HOST` header. So if you use the IP of the system first it gets cached. If you later use the FQDN, your request fails because the cached url is using the IP. https://git.knut.univention.de/univention/components/ucsschool-kelvin-rest-api/-/blob/main/kelvin-api/ucsschool/kelvin/urls.py?ref_type=heads#L85 We should add the `HOST` header to the cache key. Notes: Do we we even care if the absolute url is correct? Would anything break if we only check the path? Why is this cached at all? Is `request.url_for` that slow?
There is already an issue and a MR to fix this problem: * https://git.knut.univention.de/univention/components/ucsschool-kelvin-rest-api/-/issues/105 * https://git.knut.univention.de/univention/components/ucsschool-kelvin-rest-api/-/merge_requests/92
(In reply to Jürn Brodersen from comment #0) > Why is this cached at all? Is `request.url_for` that slow? I cannot remember exact numbers, but yes, that function is pretty slow. It iterates over all available routes further down the call chain to find a match: https://github.com/encode/starlette/blob/e11a7d8471e7b4d859ac4cc33db2ae5263463a35/starlette/routing.py#L668 And we use it or now `cached_url_for` pretty excessively throughout the routes, I think it makes sense to cache that.
The fix has been published with Kelvin version 1.9.0.