Also, I'm the guy complaining about cache
control :-).
The other related conversation is the future of mobileview itself, and
if/when/how the apps will interact w/ MW-core vs. RESTBase micro services.
Just something to keep in mind that might affect how much (if any) effort
we put into working on mobileview as opposed to investing in
RESTBase-powered services, which (IIUC) already have some caching
mechanisms to hook into.
That said, some MW API's which are not page related could benefit from
cache-control, like sitematrix & siteinfo
<https://phabricator.wikimedia.org/T41061>.
On Wed, Jun 3, 2015 at 10:09 AM, Brian Gerstle <bgerstle(a)wikimedia.org>
wrote:
Side note, do we need a lot of these headers?
X-Powered-By: HHVM/3.6.1
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Varnish: 2583358918, 1834266080
Via: 1.1 varnish, 1.1 varnish
X-Cache: cp1047 miss (0), cp1060 frontend miss (0)
X-Analytics: https=1
Set-Cookie: WMF-Last-Access=03-Jun-2015;Path=/;HttpOnly;Expires=Sun,
05 Jul 2015 12:00:00 GMT
Could save a few bytes down the wire if we nixed the unused ones.
On Wed, Jun 3, 2015 at 9:28 AM, Adam Baso <abaso(a)wikimedia.org> wrote:
Hi team -
There was a question yesterday if we had caching headers in the APIs
consumed by the apps.
I did a quick cURL on a couple URLs for Android and iOS and it seems
like maybe requests are served cold from the Varnish cache (as with many
API responses), even if there may be some memcached/Redis hot storage at
the web server for the underlying content.
Does anyone know if there's a safe approach to implement caching
headers (e.g., Cache-Control, Expires, ETag, etc.) to optimize for hot
cache hits for the API endpoints used by the apps and experimental webapps?
In particular, would we benefit from doing so on action=mobileview? Is
there a way to canonicalize the request parameters to increase the odds of
a cache hit regardless of whether iOS or Android made the first hit (either
client-side or perhaps at the edge with scare VCL)? What about for other
API endpoints?
-Adam
$ curl -s -D - "
http://en.m.wikipedia.org/w/api.php?action=mobileview&format=json&p…
-o /dev/null | grep -v GeoIP
HTTP/1.1 200 OK
Server: Apache
X-Powered-By: HHVM/3.6.1
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Vary: Accept-Encoding,X-Forwarded-Proto,Cookie
Content-Type: application/json; charset=utf-8
X-Varnish: 2886917462, 1761146385
Via: 1.1 varnish, 1.1 varnish
Transfer-Encoding: chunked
Date: Wed, 03 Jun 2015 13:20:08 GMT
Age: 0
Connection: keep-alive
X-Cache: cp1046 miss (0), cp1046 frontend miss (0)
Set-Cookie: WMF-Last-Access=03-Jun-2015;Path=/;HttpOnly;Expires=Sun, 05
Jul 2015 12:00:00 GMT
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
$ curl -s -D - "
https://en.m.wikipedia.org/w/api.php?action=mobileview&format=json&…
-o /dev/null | grep -v GeoIP
HTTP/1.1 200 OK
Server: nginx/1.6.2
Date: Wed, 03 Jun 2015 13:22:23 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: HHVM/3.6.1
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Vary: Accept-Encoding,X-Forwarded-Proto,Cookie
X-Varnish: 2583358918, 1834266080
Via: 1.1 varnish, 1.1 varnish
Age: 0
X-Cache: cp1047 miss (0), cp1060 frontend miss (0)
X-Analytics: https=1
Set-Cookie: WMF-Last-Access=03-Jun-2015;Path=/;HttpOnly;Expires=Sun, 05
Jul 2015 12:00:00 GMT
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
--
EN Wikipedia user page:
https://en.wikipedia.org/wiki/User:Brian.gerstle
IRC: bgerstle