When calling /userinfo with a If-Modified-Since header I would like the API to return 304 when if the resource has not changed.
That will reduce the load on your servers and will also make the HTTP calls quicker.
Currently that endpoint responds with none of the headers required to support conditional GET requests. It doesn’t have an ETag or Last-Modified header and in fact responds with a Cache-Control: no-cache header. So I’m guessing there is a reason they don’t allow caching of that endpoint.
1 Like
That would make sense if they do not temporary ban me (on my local machine!) because Im sending too many request…
I can relay this request, however, I believe it’s common for OIDC-related /userinfo endpoints to exhibit the current behavior of not making use of cache so I’m unsure if this will ever be considered. For example, from the docs of IBM WebSphere they also seem to follow the same approach and from a quick experimentation test it seems Google opts for the same behavior.
Additionally, have in mind that rate limiting would still most likely be applied because the server would still have to receive and process the request (it would just not return a response body) so you could still be in the same situation you are now of getting rate limited.
I would recommend that you post a question in relation to the scenario that leads to the rate limitation on your calls to that endpoint as it may be alternatives that will allow for a reduced number of calls.