New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(Conditionally) add caching headers for Plugins #36

Closed
1000TurquoisePogs opened this Issue Dec 3, 2018 · 4 comments

Comments

Projects
None yet
2 participants
@1000TurquoisePogs
Copy link
Contributor

1000TurquoisePogs commented Dec 3, 2018

Server is missing HTTP headers "Cache-control: no-store" and "Pragma: no-cache" where would be appropriate.
These should by default be included for content that has no need for caching: user settings and microservices.
However, it should be up to the developer to know if their information is better off cached or uncached.
Therefore, an opt-out is also needed.
I suggest the following:
for each dataservice definition in a pluginDefinition, an attribute "httpCaching": true/false be allowed, which controls whether or not the above headers are inserted into dataservice responses. The default should be FALSE to encourage not caching data that changes frequently.
Beyond that, the webContent body of a pluginDefinition is used to request hosting of static content. The same attribute should be valid here, but should default to TRUE as it is likely for static content caching to be desired.

@1000TurquoisePogs

This comment has been minimized.

Copy link
Contributor Author

1000TurquoisePogs commented Dec 4, 2018

scenarios:

  1. always cache
  2. never cache
  3. add always/never only if router did not make a statement on the behavior
  4. set up defaults, but let plugin override

Number 3 may have downsides in achieving the post-processing necessary to pull it off

@1000TurquoisePogs

This comment has been minimized.

Copy link
Contributor Author

1000TurquoisePogs commented Dec 4, 2018

Here's a good first cut solution - just do scenario number 4 to start with.

  1. have an optional parameter in both dataservices and webcontent that defines what default headers will be put into responses
  2. for dataservices, they can just override the default headers if they want
  3. for webcontent, these arent under control of dataservice logic, so the defaults stick.
@1000TurquoisePogs

This comment has been minimized.

Copy link
Contributor Author

1000TurquoisePogs commented Dec 4, 2018

We need to do the same for ZSS dataservices.

@1000TurquoisePogs

This comment has been minimized.

Copy link
Contributor Author

1000TurquoisePogs commented Jan 2, 2019

Let's look at an example, the tn3270 terminal app. (https://github.com/zowe/tn3270-ng2/blob/master/pluginDefinition.json)
It has a dataservice:

"dataServices": [
    {
      "type": "import",
      "localName": "terminalstream",
      "sourceName": "tn3270data",
      "sourcePlugin": "org.zowe.terminal.proxy",
      "versionRange": "^1.0.0"
    }
}

We just add httpCaching, which defaults to false, to instruct the middleware to default to "Cache-control: no-store" and "Pragma: no-cache", but allow the code to override per-call at developer discretion.

"dataServices": [
    {
      "type": "import",
      "localName": "terminalstream",
      "sourceName": "tn3270data",
      "sourcePlugin": "org.zowe.terminal.proxy",
      "versionRange": "^1.0.0",
      "httpCaching":  false
    }
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment