[11:52:49] <XioNoX>	 http://seclists.org/nanog/2018/May/218 - Dunno if known but ATT in the US does MITM
[11:57:18] <paravoid>	 vodafone had a similar thing where it downcompressed all images
[11:57:33] <paravoid>	 and injected a javascript, that added a key binding that you could press to get a better resolution
[11:57:53] <paravoid>	 not sure if they're still doing it, but they used to quite widely, across europe
[12:27:25] <ema>	 bblack: hey :) I've got some CRs for you https://gerrit.wikimedia.org/r/#/c/433338/ https://gerrit.wikimedia.org/r/#/c/433573/ https://gerrit.wikimedia.org/r/#/c/430902/ 
[12:30:24] <vgutierrez>	 ema, bblack is flying today
[12:32:53] <ema>	 vgutierrez: yeah, that's my "welcome back home" present :)
[12:33:18] <mark>	 we can do that too
[12:35:33] <Krenair>	 eddiegp, fixed
[12:59:18] <vgutierrez>	 I've pushed aborrero a little bit during the hackathon
[12:59:57] <vgutierrez>	 so an hour ago he deployed an updated mono version on toolsforge: https://phabricator.wikimedia.org/T194665
[13:00:00] <vgutierrez>	 <3
[13:00:37] <ema>	 cool!
[13:01:22] <vgutierrez>	 yup.. we should see an improvement on AES128-SHA stats over the next few days
[13:01:35] <vgutierrez>	 (as soon as bots get restarted)
[14:00:52] <elukey>	 aloha, I am actually woring on https://phabricator.wikimedia.org/T194055 to add some new info to the webrequest 1/128th sample that we have in Pivot/Turnilo
[14:01:24] <elukey>	 the idea was to add: continent, country_code (geocoded_data), isp, isp_as_number (isp_data)
[14:01:43] <elukey>	 if anybody is interested and wants to comment please do :)
[14:01:59] <vgutierrez>	 *coff*TLS*coff*
[14:02:10] <vgutierrez>	 O:)
[14:17:26] <elukey>	 I asked! We discussed a bit and the majority of analytics thinks that the TLS info should belong on a separate dataset, rather than being part of webrequest
[14:17:37] <vgutierrez>	 :D noted
[14:26:51] <wikibugs_>	 10Traffic, 10Operations: Identify bots using AES128-SHA maintainers running on toolforge - https://phabricator.wikimedia.org/T194380#4222424 (10Vgutierrez) @MaxBioHazard I'm still seeing (at least) one bot related to you using AES128-SHA, one using the account [[ https://ru.wikipedia.org/wiki/%D0%A3%D1%87%D0%B...
[16:01:36] <mobrovac>	 ema: ping?
[16:01:40] <ema>	 mobrovac: pong
[16:01:48] <mobrovac>	 quick q about Vary: Accept-Language
[16:02:32] <mobrovac>	 we'd need to start setting it for REST API responses for domains that have lang variants
[16:03:05] <mobrovac>	 but because all browsers set that header by def, we'd need some normalisation logic inside VCL
[16:03:17] <mobrovac>	 possible?
[16:03:18] <mobrovac>	 :)
[16:11:49] <ema>	 mobrovac: we do already have in place some vcl hooks to fix-up vary slotting (eg: for cookies)
[16:12:06] <ema>	 so I would say Possible: yes
[16:13:01] <mobrovac>	 ok awesome
[16:13:17] <mobrovac>	 ema: possible in the next couple of weeks? :P
[16:13:41] <mobrovac>	 could you point me to the existing code?
[16:17:10] <ema>	 wait let's me first understand the question properly now that you talk about time estimates :P
[16:17:16] <ema>	 so the idea is that you want to send Vary: A-L on API responses and you don't want that to mess with browser requests? Do browsers hit the API directly? 
[16:27:57] <ema>	 an example of normalization for Vary purposes is https://github.com/wikimedia/puppet/blob/production/modules/varnish/templates/text-common.inc.vcl.erb#L87
[16:28:14] <ema>	 or https://www.fastly.com/blog/best-practices-using-vary-header
[16:30:15] <mobrovac>	 lol ema, for the last post, i can google myself :D
[16:30:38] <mobrovac>	 on a more serious note, basically yes - we are going to have a lot of browser requests
[16:30:43] <mobrovac>	 for page previews, for example
[16:30:58] <mobrovac>	 and if you look at a page in a variant, you would need to get the same variant for the preview
[16:31:19] <mobrovac>	 and we all know the way browsers construct that
[16:31:35] <mobrovac>	 basically, we would need a normalisation of the accept-language header
[16:31:47] <mobrovac>	 hm writing it up now, i am understanding this is non-trivial
[16:31:54] <mobrovac>	 damn
[16:32:51] <ema>	 disclaimer: the cookie-related vcl normalization above is really done to avoid request coalescing on uncacheable responses, but still the main idea would be similar I think
[16:33:12] <ema>	 with the caveat that parsing and normalizing accept-language might be a pain as you mentioned
[16:33:31] <mobrovac>	 yeah, that's what i realised
[16:34:20] <ema>	 the let-me-google-that-for-you link there does show that in the context of accept-encoding it isn't the end of the world
[16:34:42] <mobrovac>	 right, but the set of implemented encodings is finite
[16:34:48] <mobrovac>	 or small enough, if you will
[16:41:41] <ema>	 mobrovac: passing the language in the URL is not a thing I guess?
[16:48:10] <mobrovac>	 nope ema, we set on the header in an rfc already
[16:52:34] <ema>	 mobrovac: to give you a rough idea, looking at 10s of traffic on a cache node I got 932 unique A-E values
[16:55:33] <ema>	 sorry, A-L
[16:55:53] <ema>	 43540 requests, out of which 4660 without A-L
[16:59:49] <mobrovac>	 that was all traffic?
[17:00:04] <mobrovac>	 huh, that's going to be a problem for browser-based requests
[17:01:04] <ema>	 that was all GET traffic on a single esams text node, yes
[17:03:28] <mobrovac>	 huh ok
[17:03:30] <mobrovac>	 grazie
[17:04:16] <ema>	 sure thing, gotta go now o/
[17:04:35] <mobrovac>	 figured as much
[17:04:38] <mobrovac>	 enjoy :)
[19:41:17] <wikibugs_>	 10Traffic, 10Operations, 10RESTBase-API, 10Services (doing): Normalise the Accept-Language header for REST API requests - https://phabricator.wikimedia.org/T195327#4223311 (10mobrovac) p:05Triage>03High
[19:41:38] <wikibugs_>	 10Traffic, 10Operations, 10RESTBase-API, 10Services (doing): Normalise the Accept-Language header for REST API requests - https://phabricator.wikimedia.org/T195327#4223325 (10mobrovac)