Výzkumníci ukazují, jak mohou otevřené tunely a IPv6 Extension Headers synchronizovat pakety do krátkých provozních špiček. V kontrolovaném experimentu naměřili přes 180násobnou koncentraci paketového toku vůči průměrné rychlosti odesílání — nikoli 180násobné zvětšení objemu dat. Článek obsahuje metodiku, limity měření i mitigace pro GRE, IPIP a další tunely.
Po velkém úspěchu prvního MobileLinux Hackdaye se vracíme do Českých Budějovic s druhým ročníkem. V pátek 30. října 2026 od 10:00 se v prostorách Jihočeské univerzity uskuteční Embedded & MobileLinux Hackday #2. Těšit se můžete na témata jako Immutable Linux na telefonech (BengalOS), U-Boot a upstream vývoj, AI optimalizace pro embedded systémy nebo otevřený hardware. Nebude chybět praktické hackování, sdílení zkušeností a možnost … více »
Dne 21. října 2026 vydal projekt Node.js bezpečnostní aktualizace opravující deset zranitelností, včetně jedné umožňující potenciální vzdálené spuštění kódu (RCE). Nejzajímavější je CVE-2026-111497, chyba dekodéru Brotli, kterou objevili výzkumníci využívající OpenAI Codex Security. Chyba je v nativním dekodéru Brotli, nikoli v samotném JavaScriptu. Speciálně vytvořený komprimovaný vstup způsobí, že dekodér zamění
… více »Francouzský výrobce kabelů Nexans upozornil na napjaté dodávky elektrických kabelů. Výstavba nové výrobní linky pro některé typy kabelů může trvat přibližně tři roky. Datacentra potřebují rozsáhlé nízkonapěťové a středněnapěťové rozvody. Poptávka roste současně s modernizací elektrických sítí. Někteří odběratelé proto uzavírají výrazně delší dodavatelské smlouvy [Reuters].
Představena byla (𝕏) virtuální platforma FLYBENCH FPV, která nováčky provede zapojením a konstrukcí dronů.
Google Chrome 156 byl prohlášen za stabilní. Přehled novinek v poznámkách k vydání. Opraveno bylo 353 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Indická společnost eMudhra po bezpečnostním incidentu, tj. kompromitaci soukromých klíčů osmi mezilehlých certifikátů své certifikační autority, opouští globální byznys s SSL/TLS certifikáty.
Dle Phoronixu zveřejnila společnost Trend Micro prostřednictvím programu Zero Day Initiative (ZDI) několik hlášení bezpečnostních zranitelností přímo na veřejném mailing listu LKML, přestože některé chyby dosud nemají opravu začleněnou do hlavní větve jádra. Mezi hlášenými problémy jsou dvě zranitelnosti s hodnocením CVSS 9.0, týkající se SMB Direct a KSMBD, které mohou umožnit vzdálené spuštění kódu. Další hlášení se týkají … více »
Správce hesel KeePassXC byl vydán ve verzi 2.8.0. Přechází na Qt 6, podporuje vkládání hesel s Waylandem, rychlé odemykání pomocí Polkitu nebo možnost nastavení klávesových zkratek (seznam změn).
„There was an error with your submission. Please make sure you are actually logged in.“Jenže přihlášený bych měl být, když tam vidím svoje jméno, tlačítko „odhlásit“ a tlačítko „Podepsat se jako Franta“, ne? Vzdávám to, komentář vložím do svého blogu a pošlu ti odkaz starým dobrým e-mailem, to bude nejlepší. Můj komentář:
Závorky stejně jako třeba čárky, středníky, dvojtečky atd. jsou rezervované znaky v proto by se tam neměly objevit (měly by být zakódované jako %29 atd.). Takže podle toho Twitter může poznat (tzn. měl by si opravit chybu, jak píše Martin), kde URL končí – leda že by se rozhodl podporovat i vkládání nezakódovaných URL (jako např. to, co zobrazují prohlížeče v adresním řádku), ale pak by skutečně nemohl jednoznačně rozhodnout, kde odkaz končí (to by tam taky mohly být mezery). Lepší by bylo, kdyby uživatel mohl vložit normální (X)HTML <a/> značku a Twitter nemusel nic „věštit“ – navíc by šel vložil skutečný odkaz, který má jak text, tak URL – ne jen samotné URL (které je navíc často ještě obfuskované nějakým „zkracovačem“). Pak by v příspěvcích nemusely být „nesmyslné klikyháky“ a jednoduše by se dalo kliknout na lidsky čitelný text (klasický odkaz). A celé je to vůbec pošahané a důkaz jak dnešní web hnije :-/ Twitter vytvořil jakýsi umělý limit na počet znaků (zřejmě asi kvůli úspornosti) a lidé pak vkládají do příspěvků zkrácená* URL. Ale ejhle, zjistilo se, že z paznaků typuU toho vkládání komentářů se mi navíc potvrdilo to, co jsem psal už dříve na Zdrojáku – služba nechá uživatele udělat nějakou práci (např. napsat komentář) a pak se teprve řeší ty nepříjemné věci (přihlašování, registrace, platby atd.), nejde o pohodlí, ale o snahu vmanipulovat uživatele do něčeho, co zase tak moc (nebo vůbec) nechce – ale je mu líto úsilí, které už tomu věnoval.http://jdem.cz/q3hx2člověk nic nevykouká a že by bylo dobré vědět, kam ten odkaz vede – tak Twitter všechny tyhle zkrácené odkazy projde (tzn. DNS překlad doménového jména + HTTP požadavek + zkoumání odpovědi) a vloží ho dotitleatributu. Někdy člověk narazí dokonce na tři URL: 1) uvnitř <a/> elementu (normálně v textu), jedna zkracovací služba 2) vtitleatributu (cílové URL) a 3) v atributuhref, zobrazuje se ve stavovém řádku po najetí myší (druhá zkracovací služba). Vážně to nikomu nepřijde padlé na hlavu? Kam se poděla ta jednoduchost a úspornost? *) navíc někdy se jim tam nevejde ani celý text příspěvku, takže používají nějaké „prodlužovací služby“, ale to je zase jiná kapitola
Tiskni
Sdílej:
Přijde vám, že se web resp. HTTP protokol dnes často používá k věcem, pro které by byl vhodnější jiný protokol?
Ano
No nič, idem ďalej písať komunikáciu s webovou aplikáciou cez xml http requesty ;).
založené na dotazu a odpovědi, kdy alespoň jedno z toho je obvykle trochu rozsáhlejší než jen pár znaků/hodnotKdyž to definuješ takhle, tak je HTTP samozřejmě naprosto v pořádku
(ale trochu mi to připomíná některá výběrová řízení ve státní správě)
Když to definuješ takhle, tak je HTTP samozřejmě naprosto v pořádkuDefinoval jsem to tak, aby to odpovídalo potřebám :). Když k tomu přidáš ještě HTTP connect, tak máš i dlouhodobá spojení multiplexovaná na aplikační úrovni.
aby to odpovídalo potřebámJakým potřebám? Můžeme říct, že HTTP vyhovuje (jakž takž) potřebám, pro které byl vytvořen (a dokonce i některým jiným). Je to tedy dobrý protokol (s tímhle tvrzením nemám problém, souhlasím s tím). Ale šlo mi o to „nadužívání HTTP protokolu“ a jeho používání pro účely, pro které nebyl ani určen, ani pro ně není vhodný. P.S. už se to řešilo jinde
IDLE a čeká. Pak mu buď ze serveru přijde upozornění na novou zprávu, nebo to klienta přestane bavit (bude chtít dělat něco jiného) a pošle DONE a další příkazy.
V HTTP (rok 1999) tohle neuděláš, protože když pošleš HTTP požadavek, už jen čekáš na odpověď a nemůžeš ho odvolat nějakým DONE nebo k němu něco doplnit. Takže se to musí obcházet a ohýbat – třeba tím, že si otevřeš dvě TCP spojení a na jednom čekáš a na druhém děláš něco jiného. Nebo čekací spojení násilně ukončíš, aniž bys přijal odpověď, a otevřeš si nové. Nebo se periodicky ptáš, jestli už přišla nová zpráva…
HTTP je v mnoha ohledech fajn a umí toho dost, ale má svoje limity – v tom budou vždycky lepší protokoly šité na míru danému účelu.
Abych byl trochu konkrétnější: už taková drobnost jako upozornění na novou zprávu (tzn. obousměrná komunikace) je docela problém.CONNECT
Upgrade: websocket…
Líbí se vám, kam se dnes web ubírá?Já z pohledu uživatele i programátora nemám až tak rád moderní "AJAXový" svět webu. Nemám nic proti modernizaci, ale HTML je naprosto nevhodné pro účel budování uživatelských rozhraní, která mají připomínat klasické aplikace. Říkejte si, co chcete, ale když už aplikace na webu, tak zlaté javovské aplety! GUI a všechno kolem (naklikané a) naprogramované raz dva, snadno se dodržují typické "GUI konvence", výkon bez problémů, kompatibilita taky... a na to ostatní nativní aplikace. Co nám před těmi 10 lety chybělo?
https://webcache.googleusercontent.com/search?q=cache:strucny.misantrop.info/mily-twittere-nezkracuj-kdyz-neumis
Tak uznávám, že není úplně košer, když jsou pod článkem, který zprostředkuje nějakou negativní zkušenost (ale to bych si je musel nechat od cesty a zeptat se na ně třeba v příštím zápisku, který bude o něčem úplně jiném, což se mi nechtělo). Nicméně co je manipulativního na těch otázkách jako takových?