[jira] [Updated] (TS-2591) Cache does not invalidate variant/alternate content types on PUT or POST
[ https://issues.apache.org/jira/browse/TS-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2591: -- Assignee: (was: Leif Hedstrom) > Cache does not invalidate variant/alternate content types on PUT or POST > - > > Key: TS-2591 > URL: https://issues.apache.org/jira/browse/TS-2591 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Reporter: Norm Paxton > Fix For: 6.0.0 > > > "Some HTTP methods MUST cause a cache to invalidate an entity. This is either > the entity referred to by the Request-URI, or by the Location or > Content-Location headers (if present). These methods are: PUT, DELETE, POST." > http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.10 > (This doesn't explicitly address variant content types, I read it as implied.) > The current caching implementation only invalidates the Request URI, and not > variant/alternate URI's. > Example: A REST service provides both xml and json documents. A client app > requests in both content-types (perhaps two different components, one expects > xml, the other json). Assume both documents (xml and json) are in the cache. > If the app PUTs a modification to the object in XML (ie, changes a User > object's email address), it should then be able to retrieve the correct > object data via a GET in json. In order to do so, the json object in the > cache would need to be invalidated, so that the cache server forwards the > request on to the REST service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2591) Cache does not invalidate variant/alternate content types on PUT or POST
[ https://issues.apache.org/jira/browse/TS-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2591: -- Fix Version/s: (was: 5.2.0) 5.3.0 > Cache does not invalidate variant/alternate content types on PUT or POST > - > > Key: TS-2591 > URL: https://issues.apache.org/jira/browse/TS-2591 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Reporter: Norm Paxton >Assignee: Leif Hedstrom > Fix For: 5.3.0 > > > "Some HTTP methods MUST cause a cache to invalidate an entity. This is either > the entity referred to by the Request-URI, or by the Location or > Content-Location headers (if present). These methods are: PUT, DELETE, POST." > http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.10 > (This doesn't explicitly address variant content types, I read it as implied.) > The current caching implementation only invalidates the Request URI, and not > variant/alternate URI's. > Example: A REST service provides both xml and json documents. A client app > requests in both content-types (perhaps two different components, one expects > xml, the other json). Assume both documents (xml and json) are in the cache. > If the app PUTs a modification to the object in XML (ie, changes a User > object's email address), it should then be able to retrieve the correct > object data via a GET in json. In order to do so, the json object in the > cache would need to be invalidated, so that the cache server forwards the > request on to the REST service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2591) Cache does not invalidate variant/alternate content types on PUT or POST
[ https://issues.apache.org/jira/browse/TS-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2591: Fix Version/s: (was: 5.1.0) 5.2.0 > Cache does not invalidate variant/alternate content types on PUT or POST > - > > Key: TS-2591 > URL: https://issues.apache.org/jira/browse/TS-2591 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Reporter: Norm Paxton >Assignee: Leif Hedstrom > Fix For: 5.2.0 > > > "Some HTTP methods MUST cause a cache to invalidate an entity. This is either > the entity referred to by the Request-URI, or by the Location or > Content-Location headers (if present). These methods are: PUT, DELETE, POST." > http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.10 > (This doesn't explicitly address variant content types, I read it as implied.) > The current caching implementation only invalidates the Request URI, and not > variant/alternate URI's. > Example: A REST service provides both xml and json documents. A client app > requests in both content-types (perhaps two different components, one expects > xml, the other json). Assume both documents (xml and json) are in the cache. > If the app PUTs a modification to the object in XML (ie, changes a User > object's email address), it should then be able to retrieve the correct > object data via a GET in json. In order to do so, the json object in the > cache would need to be invalidated, so that the cache server forwards the > request on to the REST service. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2591) Cache does not invalidate variant/alternate content types on PUT or POST
[ https://issues.apache.org/jira/browse/TS-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2591: -- Fix Version/s: (was: 5.0.0) 5.1.0 > Cache does not invalidate variant/alternate content types on PUT or POST > - > > Key: TS-2591 > URL: https://issues.apache.org/jira/browse/TS-2591 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Reporter: Norm Paxton >Assignee: Leif Hedstrom > Fix For: 5.1.0 > > > "Some HTTP methods MUST cause a cache to invalidate an entity. This is either > the entity referred to by the Request-URI, or by the Location or > Content-Location headers (if present). These methods are: PUT, DELETE, POST." > http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.10 > (This doesn't explicitly address variant content types, I read it as implied.) > The current caching implementation only invalidates the Request URI, and not > variant/alternate URI's. > Example: A REST service provides both xml and json documents. A client app > requests in both content-types (perhaps two different components, one expects > xml, the other json). Assume both documents (xml and json) are in the cache. > If the app PUTs a modification to the object in XML (ie, changes a User > object's email address), it should then be able to retrieve the correct > object data via a GET in json. In order to do so, the json object in the > cache would need to be invalidated, so that the cache server forwards the > request on to the REST service. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2591) Cache does not invalidate variant/alternate content types on PUT or POST
[ https://issues.apache.org/jira/browse/TS-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2591: -- Fix Version/s: 5.0.0 > Cache does not invalidate variant/alternate content types on PUT or POST > - > > Key: TS-2591 > URL: https://issues.apache.org/jira/browse/TS-2591 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Reporter: Norm Paxton > Fix For: 5.0.0 > > > "Some HTTP methods MUST cause a cache to invalidate an entity. This is either > the entity referred to by the Request-URI, or by the Location or > Content-Location headers (if present). These methods are: PUT, DELETE, POST." > http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.10 > (This doesn't explicitly address variant content types, I read it as implied.) > The current caching implementation only invalidates the Request URI, and not > variant/alternate URI's. > Example: A REST service provides both xml and json documents. A client app > requests in both content-types (perhaps two different components, one expects > xml, the other json). Assume both documents (xml and json) are in the cache. > If the app PUTs a modification to the object in XML (ie, changes a User > object's email address), it should then be able to retrieve the correct > object data via a GET in json. In order to do so, the json object in the > cache would need to be invalidated, so that the cache server forwards the > request on to the REST service. -- This message was sent by Atlassian JIRA (v6.2#6252)
