Https en BenchDB - Development-iteratie #85

In de afgelopen drie weken heeft het developmentteam gewerkt aan iteratie #85. In deze iteratie hebben we ons gericht op het verbeteren van de BenchDB, en hebben we de laatste stappen gezet naar de implementatie van https en http/2.

Volgende stappen BenchDB

In de vorige sprint hebben we de nieuwe BenchDB gereleased. Deze tool stelt de redactie in staat om testresultaten te beheren en mooi weer te geven in grafieken. In iteratie #85 hebben we ons gestort op het pletten van bugs en het verder uitbouwen van de BenchDB-functionaliteit, waaronder de weergave van de testresultaten in de Pricewatch. Op het specificatietabblad bij producten gaan we naast droge specificaties ook de testresultaten tonen, zodat je nog beter kunt beoordelen hoe een product presteert. De weergave van de testresultaten is nog niet klaar en kan hopelijk na de volgende iteratie worden vrijgegeven.

Https en http/2

Eerder lieten we al doorschemeren dat de overgang naar https en http/2 hoog op ons wensenlijstje staat. Het borgen van de privacy van de bezoeker, beveiliging en technisch up-to-date blijven, zijn daarvoor onze belangrijkste drijfveren. Deze iteratie hielden we ons bezig met het voorbereiden van de loadbalancers, het verder testen van scripts, en het voorbereiden van bestaande en nieuwe content op de site voor de overgang naar https.

Tweakers-meme

Om de nieuwe Tweakers-campagne kracht bij te zetten zijn we bezig geweest met het bouwen van een memegenerator. Wie kan ons immers beter helpen met het omschrijven van Tweakers voor de rest van Nederland dan onze eigen community? Met de memegenerator kun je suggesties doen voor advertentie-uitingen van Tweakers. Onder de beste inzendingen verloten we cadeaubonnen. Lees hier de .plan.

Functionele e-mails

Tweakers verstuurt heel wat functionele e-mails om gebruikers te informeren. Voorbeelden daarvan zijn: ‘Welkom bij Tweakers’ en ‘Abonnement geactiveerd’, maar er zijn er nog veel meer. Zowel tekstueel en visueel als technisch viel hier een hoop aan te verbeteren. We hebben het mailsysteem herschreven en met behulp van Twig nieuwe templates gebouwd, zowel in HTML als plain-text. Met deze iteratie laten we de eerste mails los:

• welkomst- en activatiemails;
• mails rondom het afsluiten van een abonnement;
• mails rondom shopreviews;
• mails over het toevoegen of afwijzen van shops aan de Pricewatch.

In de komende periode volgt de rest.

Reacties (77)

BenchDB

Mbt HTTPS, hoe zit dat straks eigenlijk met user content, denk bijv externe foto's in reviews e.d.?

[spoiler]Los van het mooie achtergrond artikel van ACM dat hier nog over komt[/spoiler] We willen uiteraard geen mixed content issues dus user generated content dat niet via HTTPS komt wordt via een proxy geserveerd. Tweakers haalt de HTTP content op, cached dat en serveerd een HTTPS link uit.

Ik wacht dat artikel vol spanning af

Als je zegt 'niet via HTTPS komt', zou het evt meerwaarde hebben om content zelf via HTTPS te serveren? Ik weet daar inhoudelijk weinig (lees: de ballen) van, maar als er aanpassingen zijn vanuit user content die zouden helpen sta ik daar uiteraard graag voor open.

De meerwaarde hierin is dat de gebruiker geen foutmelding krijgt (rood of in ieder geval niet groen slotje).
Dat is het enige

Nadeel van een dergelijke oplossing lijkt me wel dat Tweakers makkelijk geblacklist kan worden door een content provider.

Wordt de data ook 1 op 1 doorgesluisd, zonder enige gegevensmanipulatie?

Zitten wel wat haken en ogen aan zo'n proxy.

GitHub doet het al een ruime tijd met camo (waarvan ondertussen ook ports naar andere talen bestaan, zoals Go) en die zijn een slag groter. Zolang het doel proxyen is (dus relatief korte cacheduur, alleen beschikbaar via Tweakers, etc) lijkt me duidelijk een dergelijke maatregel niet een verkapte vorm van auteursrechtenschending is.

Dat klinkt mooi, maar hoe zit dat precies? Mag je zomaar alle content cachen/opslaan? De vraag is natuurlijk ook of je dat wilt.. Kun je bijvoorbeeld aangeklaagd worden voor copyright-zaken (of erger)?

In mijn ogen zou alles in het Publieke Domein moeten staan (die voor het 'publiek' bedoeld zijn), maar dat kun je helaas niet afdwingen.

Het is dus een grijs gebied, maar ben benieuwd naar het antwoord, zeker als je zelf ooit eens zoiets wilt doen.

ik ga er vanuit dat als je plaatjes van externe sites / servers inlaadt er geen verschil tussen het wel cashen of niet cashen,

zo was er eens een zaak tussen een of andere radio.nl en brein waarin werdt gesteld dat je het her-linken naar al reeds bestaande streams als nieuwe openbaarmaking kon laten gelden en er dus opnieuw rechten moesten worden afgedragen ook al had de stream bijv veronia of 3fm, al voor die rechten betaald.

kortom het wel of niet cashen om technische en veilgheids redenen zal niet (snel) als extra belastend worden gerekend wanneer het op copyrightschending neerkomt.

Cashen gebeurt inderdaad wel met die muziekrechten (op de verkeerde plekken)

Het was overigens niet radio.nl maar nederland.fm en volgens mij wordt daar opnieuw naar gekeken: http://www.nu.nl/internet...adiosite-nederlandfm.html

Proxy opzetten om alles vanaf de eigen domeinen te serveren bijvoorbeeld, als je dat onmiddelijk als caching opzet heb je direct het bijkomend voordeel dat een review binnen enkele jaren ook nog goed bekeken kan worden zelfs al zijn de originele afbeeldingen niet meer online beschikbaar.

Alleen slaat de proxy die wij (gaan) gebruiken niets op en houd hij alles maximaal voor een dag in zijn geheugen. Het is puur zodat die url's via https lopen.

als je dit doet, en de orriginele link word ofline gehaald dan gaat mijn hierboven genoemde beperking op copyrights niet op en kun je dus strafbaar zijn aan openbaarmaking... en moet je op zijn minst een notice-and-takedown prodecure instellen en dat ook kenbaar maken, dat lijkt me een probleem, om nog maar te zwijgen van de data/opslag kosten als het bijv om externe filmpjes gaat.

HTTPS afdwingen, als de externe content geen HTTPS support heeft de gebruiker op een link laten klikken..?

Dat is leuk in theorie, maar zo'n oplossing verlaagt de usability voor veel gebruikers als er niet-HTTPS bronnen worden gebruikt. Ik denk dat Tweakers niet zo hard op HTTPS aan het inzetten is dat ze de usability in het gedrang willen laten komen "for the cause".

Wat is het nut precies van SSL op Tweakers.net?

@Mcdronkz, SSL beïnvloedt alleen de ranking wanneer concurrerende websites ook SSL gebruiken. Dat is bij Tweakers niet het geval (wel bij banken etc)

[Reactie gewijzigd door SalimRMAF op 10 mei 2016 13:50]

Dat is nogal persoonlijk en lang niet voor iedereen even nuttig. Los van het feit dat SSL steeds meer de standaard wordt zijn er ook nog redelijk wat plekken op GoT waar (prive) discussies gevoerd worden. Denk hierbij aan een negatieve sfeer bij een bepaalde werkgever. Het zou dan vervelend zijn als dat plain text over de lijn gaat waarbij die werkgever lekker mee leest. Evenals het versturen van adres gegevens (V&A) of andere privacy gevoelige data. De een zal het belangrijker vinden dan de ander maar i.i.g. voorzien we er straks wel in

Een beetje werkgever installeert natuurlijk zijn eigen rootcertificaat op de werkcomputers en laptops en decrypt dat verkeer alsnog.

Dan is die werkgever strafbaar bezig, want ook op je werk heb je recht op privacy en dat geldt ook voor je priveinternetzaken die je doet met de bedrijfscomputer. Verder behoudt het monitoren van je werknemers in dat je bezig bent met het verwerken van persoonsgegevens en daar heb je ook weer hele wetten voor. Zonder gerechtige reden mag je niet zomaar kijken wat je werknemers precies doen op het internet, daar moet je een legitieme verdenking voor hebben.

https://securityrecht.nl/...ernetgebruik-op-het-werk/
https://autoriteitpersoon...ng/controle-van-personeel
google.nl

Dan is die werkgever strafbaar bezig

Het had beter geweest als je op Inspector gereageerd had, want puur de handeling waar Kees het over heeft is niet strafbaar. Het is zelfs vrij gangbaar dat dat gebeurt als er van transparent proxies gebruik wordt gemaakt.

Nee, want inspector had het over het beveiligen van data zodat de werkgever niet zomaar alles kan bekijken doordat het plain tekst over de lijn gaat waarop kees antwoordde hoe je die versleuteling ongedaan kan maken, het deed bij mij overkomen alsof de werkgever dit bewust zou doen om te kijken wat de werknemer doet, daarom mijn reactie op kees.

Hoe het gebeurt is irrelevant. Ook als het plain text is, is de werkgever gewoon verkeerd bezig als hij meeleest. Wat Kees voorstelt verandert dus *niets* aan de situatie

Maar dat zeg ik ook niet, mijn reactie was gebaseerd op wat ik hierboven al zei en hoe ik dacht dat de reacties bedoeld waren.

Maar snap je mijn punt?

Inspector: je wilt SSL zodat je werkgever niet kan meelezen
Kees: je werkgever kan prima meelezen als SSL gebruikt wordt als er gebruik wordt gemaakt van een self-signed CA geïnstalleerd op de workstations van de werknemers.
Rudie_V: maar dat is strafbaar.

Wat Kees zegt is niet strafbaar, wat Inspector zegt is strafbaar. Kees zegt alleen maar: als de werkgever toch al kwaad wil, gaat het gebruik van SSL hem niet tegenhouden.

Nee, ik begin je punt niet te snappen, want ik zie het anders zoals dus geschreven in de linkjes die ik gaf.

Inspector: je wilt SSL zodat je werkgever niet kan meelezen
Kees: je werkgever kan prima meelezen als SSL gebruikt wordt als er gebruik wordt gemaakt van een self-signed CA geïnstalleerd op de workstations van de werknemers.

Wat Kees zegt is niet strafbaar, wat Inspector zegt is strafbaar.

Wat inspector zegt is strafbaar? Sinds wanneer is beveiligde sites (SSL) gebruiken zodat je werkgever niet mee kan lezen strafbaar? Dat heb ik nog nooit gehoord. Dus iedereen die op z'n werk beveiligde site gebruikt is strafbaar? Dus iedereen die op het werk de prive facebook of twitter of email gebruikt is strafbaar? Heb je daar linkjes voor, want dat ik vind ik hoogst onwaarschijnlijk en heb ik nog nooit gehoord! In een tijd waar sites overgaan op beveiligde sites zeg jij dat het gebruik hiervan door de werknemer op apparatuur van de werkgever strafbaar is?

Kees zegt alleen maar: als de werkgever toch al kwaad wil, gaat het gebruik van SSL hem niet tegenhouden.

Klopt, maar als de werkgever kwaad wil en onrechtmatig het internetverkeer inkijkt wat de werknemer precies doet dan is die strafbaar, dat is wat ik zeg. Pas met gerechtigde verdenking of reden mag de werkgever je internetverkeer in gaan kijken. Dat staat in de linkjes die ik gaf. Of zijn die linkjes verkeerd, wil je dat zeggen?

Wat inspector zegt is strafbaar?

De premisse die inspector geeft is "dat je werkgever meeleest". Dat feit is strafbaar. Hoe hij dat doet doet niet ter zake.

Klopt, maar als de werkgever kwaad wil en onrechtmatig het internetverkeer inkijkt wat de werknemer precies doet dan is die strafbaar, dat is wat ik zeg

Dat is ook wat ik zeg, en dat was al de situatie waar we in de post van Inspector vanuit gingen

[Reactie gewijzigd door .oisyn op 11 mei 2016 14:40]

Duidelijk, dan zitten we weer op 1 lijn.

Of de werkgever strafbaar bezig is of niet (er zijn goede redenen om verkeer te monitoren, zoals malware bestrijding) doet niet echt ter zake. Wat ik bedoel is dat encryptie een werkgever niet dwars hoeft te zitten omdat de werkgever de computer in zijn macht heeft. Denk dus niet dat een werkgever niets kan zien wat je op het internet doet omdat het via https gaat.

Nee dat weet ik, maar je reactie deed op mij overkomen alsof de werkgever het bewust deed om mee te kijken met de werknemer, en dat mag niet zomaar. Maar zo'n proxy setup dient andere doeleinden dan het bespioneren van de werknemers.

dat is niet helemaal waar, volgens de bron die je zelf aangeeft, mag een bedrijf dit perfect doen zolang ze de privacy van personen maar in het oog houden,

werk je met privacy gevoelige data dan mag jouw worden verboden met deze pc op het internet te of op zijn minst deze data via het internet te verspreiden, daartoe mag al je 'zakelijke' email bijv worden gelogd, in geval je met klanten (of bijv patienten) te maken hebt kan het zelfs zo zijn dat deze data zelfs veplicht moet worden gelogd

dat wil niet direct zeggen dat men ook in deze data mag gaan pluizen zonder gegrondde reden, maar dat is een andere discussie.

Hoe gaan ze dat doen zonder in dit geval de private key van Tweakers?

Client + forged public key -> Proxy + forged private key + public key (echte) -> Server + public key (echte)

Als jij root hebt op de client en de proxy dan is dit een koud kunstje. Het enige probleem is dat je als je kijkt naar het SSL certificaat je zult zien dat het niet van [in dit geval] Tweakers.net is. En daarom moet je ook altijd de certificaten controleren.

Nonsens, de contents van het certificaat kunnen gewoon 1 op 1 worden overgenomen, met als uitzondering de public key en de handtekening van de CA, want die worden vervangen. Op het moment dat er op de client een trusted CA staat waar de MITM controle over heeft, dan kan die gewoon naar hartenlust willekeurige certs genereren die, afgezien van de andere CA, niet van echt zijn te onderscheiden. En trouwens, die CA kan zich ook gewoon voordoen als willekeurige vertrouwde partij, zoals Verisign. Dus nee, het zal niet erg opvallen.

[Reactie gewijzigd door .oisyn op 10 mei 2016 20:12]

Mijn voorbeeld is geen nonsens, en niets maar dan ook niets dat jij in jouw post stelt gaat in tegen mijn voorbeeld.

Op het moment dat je geen root hebt op een systeem, maar de eigenaar wel, dan heb je uberhaupt theoretisch gezien geen privacy.

Naast het voorbeeld dat ik noem en het voorbeeld dat jij noemt zijn er nog legio andere voorbeelden.

Je voorbeeld is geen nonsens, je opmerking dat je het certificaat kunt controleren is nonsens. Op het moment dat een MITM in staat is een cert te genereren die door de client wordt geaccepteerd, kan hij in dat cert zetten wat hij wil, en zal het niet van echt te onderscheiden zijn zonder de hele chain goed uit te pluizen.

Het ssl(eigenlijk tls)-certifiaat van tweakers.net (of elke andere site) wordt door de browser gevalideerd m.b.v. het publieke certificaat van een ssl-authority (bijv verisign of lets-encrypt) als dit lukt keurt je browser het certificaat goed en gaat het gebruiken voor de communicatie zo niet krijg je een waarschuwing. Je browser heeft dus een whitelist van te vertrouwen partijen die certificaten aan mogen maken. Iemand (of malware) met (beheerders) toegang tot je pc kan een extra partij aan die lijst toevoegen en zo voor elk domein "geldige" certificaten uitgeven. Op die manier is al het ssl verkeer af te luisteren zonder dat jij als gebruiker ooit een waarschuwing ziet. SSL is alleen veilig beide endpoints (client en server) en de certificaat autoriteit te vertrouwen zijn.

[Reactie gewijzigd door martijnve op 10 mei 2016 14:56]

Als tweakers aan certificaat pinning doet, wordt dit al een stuk lastiger. (zo niet onmogelijk?)

Als tweakers aan certificaat pinning doet, wordt dit al een stuk lastiger. (zo niet onmogelijk?)

Helaas zijn de browserbouwers daar in gezwicht voor grote bedrijven en geldt dat key pinning uit gezet wordt als er een niet-publieke CA cert in de chain zit.

Bijv. bescherming van je inlog gegevens tegen MITM aanvallen. Of wat dacht je van het nieuwe http/2 dat het gebruik van SSL vereist en in ruil sites kan laden met veel minder overhead?

Of wat dacht je van het nieuwe http/2 dat het gebruik van SSL vereist

Nee, HTTP/2 vereist geen encryptie. Wel kiezen browsermakers er kennelijk voor om encryptie verplicht te stellen bij HTTP/2, maar dit is 100% een implementatiekeuze en geen vereiste vanuit het protocol.

Klopt, en ik heb begrepen dat die keuze zo gemaakt is om het verkeer makkelijker door bestaande proxies te krijgen, dus niet eens per se vanwege security.

het zit inderdaad niet in de standaard (don't ask me why want spdy had het wel) maar aangezien alle browsermakers het wel vereisen mag je het defacto wel bij de standaard rekenen.

Wat is het nut precies van SSL op Tweakers.net?

Het gaat niemand iets aan wat ik doe op internet. Als ik bv een nieuwe telefoon uitzoek in pricewatch dan houd ik dat liever geheim anders krijg ik de komende drie maanden reclame voor nieuwe telefoons.

Maar die advertenties krijg je denk ik eerder mbv cookies? Vast niet door je verkeer onderweg te sniffen?

Heeft onder andere positieve gevolgen voor de ranking binnen Google:
https://webmasters.google...ps-as-ranking-signal.html

Daarnaast wordt HTTP/2 door de meeste browsers alleen in combinatie met HTTPS ondersteund.

[Reactie gewijzigd door mcdronkz op 10 mei 2016 13:50]

SSL beïnvloedt alleen de ranking wanneer concurrerende websites ook SSL gebruiken. Dat is bij Tweakers niet het geval (wel bij banken etc)

Dan gaat het dus wel de ranking beïnvloeden. Namelijk die van onze concurenten

Google beloond, websites met gebruik van goed geoptimaliseerde SSL / HTTPS. Het is geen rankingfactor en zal het ook niet zijn. Echter gebruiken momenteel veel websites steeds meer HTTPS omdat het < 1% invloed heeft op rankings. Tja.

HTTPS moet ook correct toegepast worden. Je URL mag dan wel https://www.tweakers.net/ zijn maar als je content include of inlaadt vanuit HTTP is het nog niet 'veilig' genoeg.

HTTPS is verder niet zo spannend ofzo, dan behalve dat je verbinding beveiligd is, en op open netwerken niemand kan 'sniffen' wat je op tweakers.net bijv. doet.

SSL helpt ook met het voorkomen van MITM-attacks. Zo weet je zeker dat wat je hier op Tweakers ziet, ook echt van ons afkomstig is en niet door een andere partij 'onderweg' nog is aangepast. Hierbij kun je denken aan ad-injection of censuur van content maar ook sniffing en nog vele andere nare praktijken.

Wat is het nut precies van SSL op Tweakers.net?

Je gaat er van uit dat alle netwerken tussen client en server te vertrouwen zijn. Dat is behoorlijk jaren 80 denken wees creatief, dan kun je allerlei scenarios bedenken. Ik zal je er eentje geven: WiFi in de trein. Succes.

Dat zijn weer een aantal hele mooie updates! Is de nieuwe BenchDB al in gebruik of wordt er nu nog gebruik gemaakt van de oude?

Verder lijkt er iets niet helemaal goed gegaan te zijn. Bij het openen van notificaties krijg ik de volgende melding: "Invalid BSON ID provided".

Verder krijg ik bij deze link: plan: Nieuwe BenchDB - Development-iteratie #84 de volgende foutmelding: "conditionType must be set".

Zal ook een topic aanmaken in SB.

De nieuwe BenchDB is in de backend al in gebruik, de frontend waarbij we de test resultaten zo mooi mogelijk gaan presenteren is nog in ontwikkeling. Meer daarover de volgende release

Okay, bedankt voor je reactie. Ik ben dan heel benieuwd hoe de nieuwe frontend eruit komt te zien!

Benchmarks als losse bestemming (nu nog te vinden onder 'Meer' in de hoofdnavigatie) zal verdwijnen. In plaats daarvan gaan we testresultaten toegankelijk maken via de specificatietab van producten. Op die manier wordt de vindbaarheid van de testresultaten een stuk beter en is later ook het vergelijken van testresultaten mogelijk (via de huidige specvergelijking).

In eerste instantie zal de weergave bestaan uit een simpel tabelletje met de resultaten van belangrijke tests (de tests van bijvoorbeeld ssd's leveren heel veel resultaten op die verwerkt worden tot een paar indexgetallen, de losse resultaten zijn niet interessant voor de lezer). Later willen we de weergave uitbreiden met bijvoorbeeld een vergelijking ten opzichte van de alternatieven. De focus ligt nu nog op het afbouwen van de nieuwe BenchDB. Onder andere het beheer van eenheden, tests en indices en de importtools moeten nog herschreven worden.

[Reactie gewijzigd door Femme op 10 mei 2016 16:48]

Klopt. zie hier: BSON ID error bij notificaties?

De error bij notificaties is als het goed is inmiddels gefixed!

Een bug door iteratie 85: BSON ID error bij notificaties?

Twee bugs door de iteratie: [FP] "conditionType must be set" error bij openen links

Deze error is als het goed is inmiddels gefixed.

Ik ben stiekem ook wel benieuwd naar benches van PHP7.0 op jullie code / platform.
Is daar al wat meer over bekend?

Ik ook Maar ook daar komt nog een achtergrond artikel over. We moeten uiteraard eerst over om daadwerkelijk de performance impact te kunnen waarnemen

Jullie hebben nog niet in jullie development-omgevingen getest gespeeld?

[Reactie gewijzigd door CH4OS op 10 mei 2016 15:10]

Ohjazeker wel, alleen is de load daar een stuk lager op vreemd genoeg

Dat snap ik. Maar gaat mij dan voor het moment ook niet per se over benches van de live omgeving...

Het is duidelijk sneller met php 7 dan met php 5.6, maar omdat we niet een exacte replica van onze productieomgeving hebben om op te benchmarken is het wat lastiger om te bepalen hoeveel de winst daadwerkelijk wordt.

Wellicht is de winst in productie wel minder doordat er o.a. met een database op een andere machine moet worden gecommuniceerd. Of doordat een deel van de winst wordt gemaskeerd doordat diverse requests in varnish worden bewaard. Of doordat de hit-ratio op memcached groter is in productie.

Of misschien is de winst wel groter omdat er veel meer werk tegelijk gebeurt en we juist door o.a. de besparingen in geheugengebruik een gunstigere schaling van de software of het OS krijgen.

We monitoren de performance van onze site met New Relic. Het is mijn bedoeling om die cijfers voor en na de ingebruikname van php7 met elkaar te vergelijken. En daar zullen we allicht wat aandacht aan besteden in een artikel; hoe uitgebreid die wordt weet ik nog niet

Ze zijn in ieder geval vanaf februari er al mee aan het spelen. Zie ook plan: Feedback Vraag en Antwoord - Development Iteratie #81 en latere .plans

Altijd interessant om over de development iteraties te lezen. Zelf ben ik ook bezig met een flinke update van mijn meest gebruikte website.

PHP 5.6 -> 7.0
ElasticSearch 1.6 -> 2.3
Debian 7 -> 8
HTTP 1.1 -> 2
+ SSL implementatie

Komt toch heel wat bij kijken en zeker met veel gebruikers mag er niks mis gaan wanneer alles live gaat Dus altijd leuk om even mee te lezen hoe jullie de overgang naar PHP7, HTTP/2 en SSL implementeren. Vooral: testen testen testen.

Je vergeet nog: testen, testen, testen.

Maar inderdaad, het is voornamelijk veel testwerk, want in theorie kan alles stuk gaan, dus moet je alles testen. Nu zal http/2+ssl niet heel veel stuk maken, maar om het performant op te zetten is wel een uitdaging.

Las je al mee tijdens het typen? Als laatste zin nog toegevoegd voordat ik de reactie plaatste. Ik wil zelf ook alles over SSL laten verlopen, mijn eerste website met SSL dus dat is wel wat uitzoek werk.

Ik wil natuurlijk ook niet hebben dat mijn SSL certificaat straks een keer verlopen is en alles vanuit Google naar de https variant linkt, waarna je vervolgens een beveiligingswaarschuwing krijgt (in Chrome in ieder geval).

Dan kan ik je sterk aanraden om eens een kijkje te nemen naar https://letsencrypt.org/. Als je dat goed instelt zal je certificaat nooit verlopen en het is ook nog eens gratis!

Lijkt me nog een hele kluif om over te gaan naar https en http/2.
Ik zie dat jullie Varnish en Apache gebruiken.
Zelf gebruik ik een fysieke load balancer die offload naar Varnish met daar achter nginx.
Zowel de load balancer als Varnish doen niet aan http/2, heb laatst wat zitten testen maar het niet voor elkaar gekregen.
Ben benieuwd naar jullie nieuwe setup.

Wij hebben hierbij uiteindelijk een mazzeltje gehad met de gekozen nieuwe loadbalancers. Ze kunnen bij de SSL-offloading ook automatisch http/2 nemen als de browser dat ondersteund.
Als dat niet had gekund, dan hadden we verder moeten zoeken en zouden we misschien wel bij H2O in proxy-modus zijn uitgekomen.

Zodra we de https-release achter de rug hebben, volgt ook een artikel met uitleg wat we zoal moesten aanpassen en hoe we e.e.a. opgelost hebben

Ik dacht al dat er iets aan de hand was omdat de layout niet klopte. En tadaa... Daar is de .plan

Haha je weet dat er een .plan aan zit te komen als de hele layout door elkaar zit

Mooi dat in het voorbeeld van de memegenerator de tekst niet op het plaatje past..

Wat past er niet dan?

Plaatje is inmiddels aangepast. De tekst past nu wel

Thanks, heb even de meme vervangen