Uploaden fotoalbum en private storage werkt niet

[frickY]

Ik probeer een foto (95,9 KB) te uploaden in mijn fotoalbum maar krijg de volgende foutmelding

In Chrome 52.0.2743.116 m (64-bit);
[quote]This site can’t be reached

The connection was reset.
Try:
• Checking the connection
• Checking the proxy and the firewall
ERR_CONNECTION_RESET

Chrome HAR dump

edit:
irrelevant

In Firefox 48.0.2;
[quote]Secure Connection Failed

The connection to the server was reset while the page was loading.

• The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
• Please contact the website owners to inform them of this problem.
Firefox HAR dump;

edit:
irrelevant

Het uitzetten van mijn antivirus (nod32) maakt geen verschil.\

edit:
Pause protection helpt niet. HTTPS Scanning volledig disablen wel

Hetzelfde probleem treed ook op als ik upload naar mijn private storage.

Met IE11 lukt het wél
dump

edit:
irrelevant

Wellicht een issue met HTTP/2?

[ Voor 136% gewijzigd door frickY op 09-09-2016 18:49 ]

[Hero of Time]

Klinkt vergelijkbaar met o.a. Probleem bij het plaatsen van een aanbod advertentie, JPG naar T.net album uppen: ERR_CONNECTION_RESET en [Bug]Foto uploaden in V&A geeft foutpagina

[frickY]

Die lijken me inderdaad hetzelfde. Had die zelf niet gezien.

Ik zou het probleem in de vTM's zoeken.
Heb zelf eens iets vergelijkbaars gehad toen mn client_body_buffer_size te laag stond in een Nginx forwarding-proxy.

[ Voor 37% gewijzigd door frickY op 08-09-2016 11:49 ]

[frickY]

Ik heb het met een vergelijkbare setup (windows 64x, chrome, nod32) op mijn werk niet.
Het probleem zou ook slechts met één van de loadbalancers kunnen zijn. Zal vanavond thuis kijken of het daar nog/weer speelt.
Nogmaals, ik zou het zoeken in de (HTTP/2) request-size configuratie.

[ Voor 26% gewijzigd door frickY op 08-09-2016 11:49 ]

[crisp]

Het lijkt hem inderdaad te zitten in het opzetten van de connectie. Ik zal kees er weer eens op wijzen

[frickY]

Het heeft niets met HTTP/2 of IPv6 van doen.
Een bijlage van 1kb lukt wel. 50kb niet.
Ik probeer nu te vinden wat de exacte request size is vanaf waar het mis gaat.

//edit
Met een bijlage van 47.715 bytes en kleiner lukt het. Alles er boven geeft dit probleem.
Tel daar wat headers ed. bij en ik vermoed dat het omslagpunt bij request sizes van 50kb ligt.

//edit
Vreemd. In Firefox werkt het slechts met een bijlage tot en met 16.352 bytes.
Het hele request incl headers is dan 18.865 bytes

[ Voor 55% gewijzigd door frickY op 08-09-2016 21:06 ]

[crisp]

Het hele vervelende is dat wij het zelf stomweg niet kunnen reproduceren. Het lijkt ook browser-afhankelijk, want bij soortgelijke meldingen lukt het mensen wel in bijvoorbeeld Edge. En als dit een algemeen probleem zou zijn dan zouden er veel meer mensen met dit probleem zijn. Er speelt dus m.i. wel degelijk nog iets mee aan de client (netwerk) kant, maar de grote vraag is wat precies..

We staan dus nog steeds voor een raadsel...

[ Voor 31% gewijzigd door crisp op 08-09-2016 21:07 ]

[frickY]

Dat begreep ik inderdaad vanuit de andere topics. Vandaar dat ik me best doe met behulpzame informatie te komen.
Het lijkt er in ieder geval op dat de verbinding in een vroeg stadium wordt afgekapt. Nog voor de ssl handshake, en dat de browsers daarom met een "Secure Connection Failed"-melding komen.

Enige verschil in request headers tussen Chrome en Firefox en IE11 is dat die eerste 2 een "Upgrade-Insecure-Requests: 1" meesturen en IE niet.

Request size heeft er ook mee te maken, gezien ik het probleem kan oplossen met een hele kleine bijlage. Maar het verschil in grootte tussen Chrome en Firefox snap ik ook niet.

Ik zal proberen of Fiddler wat concreters oplevert. Vind het zelf nu ook wel interessant worden

//edit
Met Fiddler als proxy werkt het uploaden van grote bestanden prima

[ Voor 28% gewijzigd door frickY op 08-09-2016 21:36 ]

[crisp]

frickY schreef op donderdag 08 september 2016 @ 21:17:
Dat begreep ik inderdaad vanuit de andere topics. Vandaar dat ik me best doe met behulpzame informatie te komen.

[...]

Much appreciated ook Hoe meer aanwijzingen hoe beter...

[frickY]

Het is toch een lokaal probleem, en de oorzaak is NOD32. Specifiek de HTTPS Scanner.
Daar is iets mis mee, want als ik het uitzet is het probleem weg.

Met die kennis kun je iets gerichter zoeken en vind je bijvoorbeeld (al wel al gedateerd);

ESET has a bug where they drop any connections where the ClientHello is larger than 256 bytes

Chrome en Firefox gebruiken wel ECDHE_RSA key exchange en IE ECDH_P256. Wellicht dat dit dan de NOD32 bug net wel/net niet triggert vanaf een bepaalde request size.
Verklaard niet waarom het op mijn werk waar ik dezelfde NOD32 gebruik wel werkt.


Als ik de https-scanner aanzet is het probleem terug, tot ik hem het tweakers certificaat laat ignoren en uploaden weer werkt.
Wat mij betreft case-closed en een probleem met NOD en niet met Tweakers. Waarschijnlijk wel getriggert door jullie certificaat, en daarom opgelost toen Fiddler er het zijne tussen stopte.

Ik heb een pcap-file van het moment dat het probleem optreed. Ik zelf kan daar weinig mee. Zal kijken of Eset er wat mee wilt.

[ Voor 60% gewijzigd door frickY op 08-09-2016 23:01 ]

[crisp]

frickY schreef op donderdag 08 september 2016 @ 22:17:
Het is toch een lokaal probleem, en de oorzaak is NOD32. Specifiek de HTTPS Scanner.
Daar is iets mis mee, want als ik het uitzet is het probleem weg.

[...]

We (may) have a winner! Ben benieuwd of dat bij anderen ook de oorzaak is, maar mega dat we nu een sterke aanwijzing hebben van de oorzaak

[frickY]

Ik heb een support-case lopen bij Eset Nederland maar dit gaat verschrikkelijk traag. Tot nu toe nog niets bruikbaars uit voortgekomen.

Ik verdenk zelf een combinatie van Nod32, jullie SSL-certificaat, en een bepaalde Windows update.

Hebben jullie nog ergens een subdomein met een ander SSL-certificaat, maar die wel via dezelfde hops (loadbalancer) loopt?

[ Voor 25% gewijzigd door frickY op 22-10-2016 11:54 ]

[_David_]

Je kan de tweakblogs proberen, die zitten op een apart wildcard certificaat.

[frickY]

Op Tweakblogs hetzelfde probleem als ik multipart/form-data payload aan mn request meegeef.
Dat pleit het certificaat weer vrij.
Hetzelfde truukje geeft op de site van bijv Eset zelf geen probleem.

Weet iemand een ander site die achter een Fortinet gateway draait?

[ Voor 35% gewijzigd door frickY op 22-10-2016 14:34 ]