[ASP.NET][troll] Een grote clientside overhead faal?

Pagina: 1
Acties:
  • 521 views

Onderwerpen


Acties:
  • 0 Henk 'm!

  • Skinkie
  • Registratie: Juni 2001
  • Laatst online: 09-06-2020

Skinkie

Op naar de 500

Topicstarter
Om weer eens een leuke post te maken op GoT, en om aan te tonen hoe belachelijk ASP.net werkt, dan wel de developers die er mee werken, een pragmatische doch interessante vraag.

Je kent ze wel de grote websites die asp.net draaien. Per definitie is de overhead groot, de javascript wordt overal en nergens vandaan geladen. Microsoft dacht slim te zijn om AJAX dan maar 'on demand' aan en uit te schakelen op basis van een user-agent om dat nog een beetje te compenseren.

De website wordt meestal getypeerd door een AJAX gebruik met een aantal clientside variabelen

code:
1
2
3
4
5
__EVENTTARGET
__EVENTARGUMENT
__EVENTVALIDATION
__LASTFOCUS
__VIEWSTATE


Tevens kan Microsoft gratis en voor niets "delta's" van de pagina sturen, mits de variabele '__ASYNCPOST': 'true' wordt gepost en de header X-MicrosoftAjax: Delta=true wordt gezet. Nou je zou denken, dat heeft Microsoft toch mooi opgelost. Je kunt lekker heen en weer posten en het is transparant voor de eindgebruiker. Not 8)7

Om voor mij een totaal onduidelijke reden bevat de __VIEWSTATE variable een Base64 objecttree die de hele 'interactie van de pagina' zou moeten representeren. Dit zorgt er voor dat alle acties op de client bij de volgende post eerst worden gevalideerd tegen wat de client heeft terugstuurd en niet wat er op de server staat. Waarom boeit dit?

Niet al te kleine sites als rechtspraak.nl, ret.nl, veolia-transport.nl, ..., presteren het om een __VIEWSTATE en __EVENTVALIDATION te kiezen die tot 500kb per request groot is. Dus voor iedere actie die heen en weer wordt gepushed wordt 500kb aan overhead gedownload en bij de AJAX post geupload.


De super voor de handliggende vraag: welke incompetent genootschap scriptkiddies zou asp.net zo kreupel maken dat z'n eigen webserver op z'n gat gaat bij een beetje verkeer omdat de bandbreedte gewoon op is. Waarom zijn dit geen incideren maar structurele asp fails? De eerste hit op google met viewstate overhead beschrijft de oorzaak, waarom asp.net dit pattern gewoon toe?

Steun Elkaar, Kopieer Nederlands Waar!


Acties:
  • 0 Henk 'm!

  • Avalaxy
  • Registratie: Juni 2006
  • Laatst online: 11:33
Je hebt het over ASP.NET terwijl je volgens mij alleen maar op webforms doelt? 8)7

Acties:
  • 0 Henk 'm!

  • Megamind
  • Registratie: Augustus 2002
  • Laatst online: 10-09 22:45
Idd, gebruik dan gewoon MVC.NET ipv webforms, heb je ook je hele viewstate niet meer :)

Acties:
  • 0 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
Het is inderdaad een mooi troll topic geworden. Het is toch écht de schuld van diegene die zo'n site bouwt. In PHP worden er net zo'n brakke, SQL injection gevoelige, XSS vatbare, sites gebouwd waarin in de URL de PHPSESSIONID wordt gemikkerd (om maar eens wat te roepen). En dan de Java meuk die niet vooruit te branden is...

Allemaal vooroordelen en stereotypen die helemaal niet waar zijn of hoeven te zijn. En daarmee ook 't eind van dit topic. Geen zin om hier straks tussen 't over-en-weer geflame te moeten gaan zitten uitzoeken wie nou wie op z'n teentjes getrapt heeft.

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Dit topic is gesloten.