To return expected results, you can:
Reduce the number of search terms.
Each term you use focuses the search further.
Check your spelling.
A single misspelled or incorrectly typed term can change your result.
Try substituting synonyms for your original terms.
For example, instead of searching for "java classes", try "java training"
Did you search for an IBM acquired or sold product ?
If so, follow the appropriate link below to find the content you need.
Version 6.0.0 introduced the
Cache Response to POST and PUT Requests
option to the document cache policy of the XML manager. This option allows for specific caching use cases, which include web services caching.
For example, most web services use the POST request exclusively. Responses to POST requests are cacheable according to the specification, but only when the responses include explicit freshness information. Additionally, a secondary caching key beyond the resource URI is typically needed to distinguish the response for one POST request from another. This secondary key could be achieved by use of the
Vary
header, but DataPower does not support the
Vary
header as a secondary caching key.
Most web services that could benefit from caching would not respond to requests with the explicit freshness information nor the
Vary
header.
Therefore, a solution was needed in the web services gateway that sits in front of these web services.
You can enable the
Cache Response to POST and PUT Requests
option only when the
Fixed
caching policy type is selected. The
Fixed
caching policy type violates the HTTP 1.1 specification with respect to caching when determining whether or not a response can be cached, and the time to live (TTL) of a cache response. With the
Fixed
caching policy type, the majority of the HTTP cache control headers are ignored. Instead, the response is forced to be cached for as long as specified in the
TTL
property of DataPower caching policy.
Beyond the violations associated with the
Fixed
caching policy type, the
Cache Response to POST and PUT Requests
option violates the following aspects of the HTTP 1.1 specifications.
RFC 7231 section 4.3.3
states "Response to POST requests are only cacheable when they include explicit freshness information." With the option enabled, DataPower caches the response to a POST request regardless of the freshness information.
RFC 7231 section 4.3.4
states "Response to the PUT method are not cacheable." With the option enabled, DataPower caches the response to a PUT request.
RFC 7234 section 2
states "The primary cache key consists of the request method and target URI."
DataPower only uses the target URI as the primary cache key. If a secondary cache-key is needed, specify one using the x-dp-cache-key HTTP header.
RFC 7234 section 4
states "A cache MUST write through requests with methods that are unsafe to the origin server." With the the option enabled, DataPower does not write through PUT and POST requests to the origin server that have fresh responses in the cache.
RFC 7234 section 4.4
states "A cache MUST invalidate the effective Request URI as well as the URI(s) in the Location and Content-Location response header fields (if present) when a non-error status code is received in response to an unsafe request method." With the option enabled, DataPower does not invalidate existing cached entries on PUT and POST requests.
[{"Product":{"code":"SS9H2Y","label":"IBM DataPower Gateway"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"General","Platform":[{"code":"PF009","label":"Firmware"}],"Version":"6.0.0;6.0.1;7.0.0;7.1","Edition":"Edition Independent","Line of Business":{"code":"LOB45","label":"Automation"}}]
