openstack-api-sig

Openstack APIs and RFC 7234 HTTP caching

Bug #1747935 reported by Fred De Backer
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Invalid
Wishlist
Unassigned
openstack-api-sig
Fix Released
Medium
Unassigned

Bug Description

Description
===========
I recently hit an issue where I was using Terraform through an HTTP proxy (enforced by my company IT) to provision some resources in an Openstack cloud. Since creating the resources took some time, the initial response from openstack was "still creating...". Further polling of the resource status resulted in receiving *cached* copies of "still creating..." from the proxy until time-out.

RFC7234 that describes HTTP caching states that in absence of all headers describing the lifetime/validity of the response, heuristic algorithms may be applied by caches to guesstimate an appropriate value for the validity of the response... (Who knows what is implemented out there...) See: the HTTP caching RFC section 4.2.2 <https://tools.ietf.org/html/rfc7234#section-4.2.2>.

The API responses describe the current state of an object which isn't permanent, but has a limited validity. In fact very limited as the state of an object might change any moment.

Therefore it is my opinion that the Openstack API (Nova in this case, but equally valid for all other APIs) should be responsible to include proper HTTP headers in their responses to either disallow caching of the response or at least limit it's validity.

See the HTTP caching RFC section 5 <https://tools.ietf.org/html/rfc7234#section-5> for headers that could be used to accomplish that.

For sake of completeness; also see https://github.com/gophercloud/gophercloud/issues/727 for my initial client-side fix and related discussion with client-side project owners...

Expected result
===============
Openstack APIs to include header(s) from RFC7234 section 5 <https://tools.ietf.org/html/rfc7234#section-5> to either disallow caching or to specify a meaningful lifetime or to force/implement revalidation options.

Actual result
=============
No headers controlling caching present whatsoever.

Revision history for this message
Chris Dent (cdent) wrote :

I've added api-sig to this because the fact that this issue has shown up in the wild should be good motivation for us to make a guideline about how to address it. The code for adding the requisite headers to placement may be a useful starting point: https://review.openstack.org/#/c/521640/

Changed in openstack-api-wg:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Sylvain Bauza (sylvain-bauza) wrote :

I'm tempted to consider such HTTP headers modification as a feature as per the Nova policy about bugs vs. features, hence the Wishlist importance.

I also wonder if it would be better to rather create a blueprint in https://blueprints.launchpad.net/nova/ and add a new spec if it needs an API microversion.

Given it's possibly something the API SIG would be discussed before Nova, let's invalid now for Nova that bug report, and ask to create the Nova blueprint only after the API SIG discussed that and has a consensus.

Changed in nova:
status: New → Confirmed
importance: Undecided → Wishlist
status: Confirmed → Incomplete
status: Incomplete → Invalid
Revision history for this message
Chris Dent (cdent) wrote :

Sylvain I'm afraid I have to disagree with you on making this "wishlist" and "invalid". The orignal poster describes a real bug that is caused by a poor behavior on the part of the compute API: "Further polling of the resource status resulted in receiving *cached* copies of "still creating..."

There's more context in http://specs.openstack.org/openstack/nova-specs/specs/queens/approved/placement-cache-headers.html (and the links it makes to the HTTP spec) about the need for the 'no-cache' header to be strictly correct in the face of aggressive proxies.

I think keeping this as a bug will help to contextualize any future work more correctly. What do you think?

Revision history for this message
Dmitry Tantsur (divius) wrote :

I tend to agree with Chris, it looks like an issue with the HTTP implementation rather than a feature. After all, if I understand the standard right, the proxy behaviour is correct.

Revision history for this message
Michael McCune (mimccune) wrote :

just chiming in to support Chris and Dmitry, this smells more and more like a bug to me as i read the background material.

i'm +1 for defining this behavior as a bug and also creating a guideline around it.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to api-wg (master)

Reviewed: https://review.openstack.org/550468
Committed: https://git.openstack.org/cgit/openstack/api-wg/commit/?id=b585c8485d86c2ec9bc19d9f99ab442f9b375374
Submitter: Zuul
Branch: master

commit b585c8485d86c2ec9bc19d9f99ab442f9b375374
Author: Chris Dent <email address hidden>
Date: Wed Mar 7 13:09:40 2018 +0000

    Add guidance on needing cache-control headers

    This adds some practical guidance to the existing section on caching
    to make it clear that where responses are not making explicit
    assertions about controlling cache, they MUST "cache-control: no-cache"

    Change-Id: If13a5a19ff077cd9a2c9c400c24af70ea6f818d9
    Closes-Bug: #1747935

Changed in openstack-api-wg:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.