Change Details

When storing parsoid output in the parser cache, we need to set an appropriate cache expiry time, taking into account any dynamic content embedded in the input (compare ParserOutput::getCacheExpiry). This cache expiry time should also be use for the Cache-Control header of the HTTP resonse, together with expiry info coming from RevisionContentHelper to account for supressed (private!) revisions. (make sure we are converting correctly between absolute time stamp and remaining seconds). We should also send the must-revalidate flag. NOTE: cache expiry is currently hard-coded to 5 seconds in PageContentHelper. Find out why, and if we can change it. NOTE: Consult with the traffic team! The cache control header currently received from RESTbase (via varnish) is: `s-maxage=1209600, max-age=0, must-revalidate`. NOTE: We probably want to mark the stashed flavor (etag has /stash at the end) as non-cacheable, to avoid dup,icate cache entries.

The page/html and page/revision endpoints serve HTML generated by parsoid. We need to determine how we want the web cache layer and client side http cache to handle this data. When storing parsoid output in the parser cache, we need to set an appropriate cache expiry time, taking into account any dynamic content embedded in the input (compare ParserOutput::getCacheExpiry). This cache expiry time should also be use for the Cache-Control header of the HTTP resonse, together with expiry info coming from RevisionContentHelper to account for supressed (private!) revisions. (make sure we are converting correctly between absolute time stamp and remaining seconds). We should also send the must-revalidate flag. NOTE: cache expiry is currently hard-coded to 5 seconds in PageContentHelper. This is probably because we wanted to avoid the need for active purging. NOTE: Consult with the traffic team about cache duration and active purging! The cache control header currently received from RESTbase (via varnish) is: `s-maxage=1209600, max-age=0, must-revalidate`. NOTE: We probably want to mark the stashed flavor (etag has /stash at the end) as non-cacheable, to avoid duplicate cache entries. we will also have to differentiate between plain HTML and HTML in a JSON wrapper.

The page/html and page/revision endpoints serve HTML generated by parsoid. We need to determine how we want the web cache layer and client side http cache to handle this data. When storing parsoid output in the parser cache, we need to set an appropriate cache expiry time, taking into account any dynamic content embedded in the input (compare ParserOutput::getCacheExpiry). This cache expiry time should also be use for the Cache-Control header of the HTTP resonse, together with expiry info coming from RevisionContentHelper to account for supressed (private!) revisions. (make sure we are converting correctly between absolute time stamp and remaining seconds). We should also send the must-revalidate flag. NOTE: cache expiry is currently hard-coded to 5 seconds in PageContentHelper. Find out why, and if we can change itThis is probably because we wanted to avoid the need for active purging. NOTE: Consult with the traffic team about cache duration and active purging! The cache control header currently received from RESTbase (via varnish) is: `s-maxage=1209600, max-age=0, must-revalidate`. NOTE: We probably want to mark the stashed flavor (etag has /stash at the end) as non-cacheable, to avoid dup,licate cache entrieses. we will also have to differentiate between plain HTML and HTML in a JSON wrapper.