[Yahoo-eng-team] [Bug 1747935] Re: Openstack APIs and RFC 7234 HTTP caching

2018-04-26 Thread OpenStack Infra 
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 
Date:   Wed Mar 7 13:09:40 2018 +

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

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1747935

Title:
  Openstack APIs and RFC 7234 HTTP caching

Status in OpenStack Compute (nova):
  Invalid
Status in openstack-api-sig:
  Fix Released

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
  .

  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
   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 
 to either disallow caching or 
to specify a meaningful lifetime or to force/implement revalidation options.

  Actual result
  =
  No headers controlling caching present whatsoever.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1747935/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1747935] Re: Openstack APIs and RFC 7234 HTTP caching

2018-02-08 Thread Sylvain Bauza 
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

** Changed in: nova
   Importance: Undecided => Wishlist

** Changed in: nova
   Status: Confirmed => Incomplete

** Changed in: nova
   Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1747935

Title:
  Openstack APIs and RFC 7234 HTTP caching

Status in OpenStack Compute (nova):
  Invalid
Status in openstack-api-sig:
  Confirmed

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
  .

  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
   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 
 to either disallow caching or 
to specify a meaningful lifetime or to force/implement revalidation options.

  Actual result
  =
  No headers controlling caching present whatsoever.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1747935/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1747935] Re: Openstack APIs and RFC 7234 HTTP caching

2018-02-07 Thread Chris Dent 
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/


** Also affects: openstack-api-wg
   Importance: Undecided
   Status: New

** Changed in: openstack-api-wg
   Status: New => Confirmed

** Changed in: openstack-api-wg
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1747935

Title:
  Openstack APIs and RFC 7234 HTTP caching

Status in OpenStack Compute (nova):
  New
Status in openstack-api-sig:
  Confirmed

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
  .

  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
   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 
 to either disallow caching or 
to specify a meaningful lifetime or to force/implement revalidation options.

  Actual result
  =
  No headers controlling caching present whatsoever.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1747935/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp