Validátor je skvělý nástroj, který kontroluje váš web na neviditelné vady. Je jich mnoho, ale Sonar je jiný než všechny ostatní. Je to jediný testovací nástroj, který si klade za cíl komplexně ověřovat webové stránky, je open source a řízený komunitou a má integraci do prohlížeče. Proč frontendoví vývojáři potřebují komplexní testovací nástroj? Proč je důležitá nezávislost na jakémkoli velkém softwarovém dodavateli? A nakonec – má Sonar potenciál a je nyní užitečný nástroj? Shromáždil jsem několik významných poznámek o jeho kvalitě.
K čemu jsou validátoři dobří?
Ve webovém vývoji se věnuji více než 17 let. Rád sleduji, jak se World Wide Web v průběhu času mění. Některé moderní přístupy se standardizují, zatímco jiné upadají do zapomnění. Setkal jsem se s velmi dobrými (HTML5 od Iana Hicksona), velmi špatnými (RSS od Davea Winera) a velmi kontroverzními (CSS úroveň 1 podle W3 Consortium) specifikacemi. Někdy je specifikace špatná, jindy implementace nesprávná. Validátory pomáhají při maximalizaci webové kompatibility, ale mohou vás také učinit 100% kompatibilními s jednou softwarovou společností za cenu porušení kompatibility s desítkami dalších firem. V podstatě existují dvě možnosti. Za prvé použijte co nejvíce validátorů a iterujte pro minimalizaci počtu chyb, nebo za druhé použijte jeden univerzální nezávislý validátor, který zná nejlepší možné techniky pro vás.
Momentálně používám tyto validátory:
- Bing Markup Validator
- Nástroj pro testování přívětivosti Bing Mobile
- Bing SEO analyzátor
- Facebook Debugger
- Google Lighthouse
- Google PageSpeed Insights
- Google Mobile Friendly Test
- Google nástroj pro testování strukturovaných dat
- Nu Html Checker
- Qualys SSL Server Test
- Sonar
- Validátor Twitter karet
- Validační služba CSS W3C
- Služba validace značení W3C
- Yandex Structured Data Validator
Podívejme se na Sonar
Jak sonar, tak modern.IE jsou vytvořeny vývojářským týmem IE/Edge. Proč byl modern.IE ukončen a proč sonar nezahrnuje ověření konfiguračního schématu prohlížeče?
Nemyslím si, že webová stránka s HTTP hlavičkou Content-Type: application/xhtml+xml musí obsahovat parametr HTTP charset, protože kódování XML dokumentu je ve výchozím nastavení UTF-8.
Souhlasím, že CSS styl podávaný s Content-Type: text/css HTTP hlavičkou by měl mít parametr charset=utf-8, ale proč to už není opraveno v ASP.NET Core 2?
Doporučení ohledně režimů IE dokumentů je velmi vtipné. Za prvé, pokud je stránka servírována jako application/xhtml+xml, IE 9 a novější budou používat XML parser a vynutit režim nejvyšších dostupných standardů. Za druhé, i když pošlu typ obsahu jako text/html, opravdu nemusím používat hlavičku nebo metatag X-UA-Compatible, abych se vyhnul režimu kompatibility, protože pokud stránka obsahuje HTML5 Doctype, IE 6 a novější automaticky použijí režim nejvyšších dostupných standardů (v případě IE 6 pouze pokud je XML prolog vynechán). Sonar by to měl nejprve zkontrolovat, než začne šířit poplachové zprávy.
Je zajímavé, že během Microsoft Edge Web Summit byl doporučený typ obsahu pro soubory ECMAScript application/javascript a nyní je doporučený typ obsahu text/javascript. Nicméně RFC 4329 z roku 2006 doporučuje application/javascript. Sonar by měl alespoň upozornit, které prohlížeče stále nejsou kompatibilní s tímto standardem. Mimochodem, ASP.NET Core 2 poskytuje soubory s .js příponou jako application/javascript.
Nemyslím si, že by HTTP hlavička X-Content-Type-Options musela být specifikována, když server posílá statické soubory, které nejsou uživatelsky generované.
Nemyslím si, že musí být při odesílání stylů, skriptů nebo obrázků uvedena hlavička HTTP Strict-Transport-Security. Server přesměruje uživatele z HTTP na HTTP+TLS a nastavuje hlavičku HSTS při prvním požadavku. Styly, skripty a obrázky se stahují později, takže hlavička HSTS již není v platnosti. Situace je jiná, když jsou tyto zdroje načteny z jiné domény. Sonar by měl tyto dva případy rozlišit a chybu zobrazit pouze tehdy, když je doména odlišná.
Proč by soubory CSS nebo ECMAScript měly mít parametr charset=utf-8 v hlavičce Content-Type? Předpokládejme, že agent ignoruje BOM nebo má server soubor kódovaný v UTF-8 bez BOM. Problém je pouze tehdy, když soubor obsahuje znaky mimo ASCII. Sonar by to měl vzít v úvahu.
Sonar nezobrazí varování, když stránka použije kompresi obsahu na šifrovaném připojení a není použito kódování přenosu v částech. Tyto tři podmínky činí stránku zranitelnou vůči útoku REACH .
Souhlasím, že hlavičky Server a X-Powered-By jsou zbytečné a mohly by představovat bezpečnostní riziko, ale proč jsou Azure Web Apps nastavené tak, aby je odesílaly, a proč výchozí šablona pro ASP.NET (Core) aplikace je neodstraní v web.config souboru?
Nemyslím si, že je chyba podávat obrazový soubor, který může být o 44 % menší. Za prvé, Sonar by to měl detekovat jako varování. Za druhé, proč System.Drawing.Bitmap kóduje obrázky do PNG formátu s tak hroznou efektivitou?
Závěr
Sonar je ambiciózní projekt, který má potenciál podobný Lighthouse. Na druhou stranu se zdá, že Sonar je v rané fázi vývoje. Musí se stát prvotřídním občanem v F12 DevTools, protože Google může prosadit svou interpretaci standardů prostřednictvím Lighthouse v Chrome DevTools. Nakonec by jej měl přijmout tým Bing, který má hluboké znalosti webu a může zlepšit kvalitu Sonaru tak, aby překonal Lighthouse.