Organizace Apache Software Foundation (ASF) vydala verzi 18 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Byla vydána verze 1.70.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example. Jako reakce na rostoucí obavy z vlivu korporací na vývoj Rustu a předložený návrh restriktivních zásad používání ochranných známek Rustu, byl nedávno představen komunitní fork Rustu se 100 % méně byrokracie: Crab (CrabLang).
Oliver Smith z Canonicalu shrnuje základní vlastnosti „neměnné“ distribuce Ubuntu Core také ve srovnání s protějšky Chrome OS, Fedora Silverblue a MicroOS. Canonical připravuje desktopovou variantu Ubuntu Core vedle dosavadní serverové/embedded.
Z aktualizovaného seznamu chyb (pdf) procesoru AMD EPYC 7002: #1474 - procesor se po 1044 dnech od posledního resetu zasekne [reddit].
Fossil (Wikipedie) byl vydán ve verzi 2.22. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
David Malcolm se ve svém příspěvku na blogu vývojářů Red Hatu rozepsal o vylepšeních statické analýzy (volba -fanalyzer) v GCC 13.
Byla vydána nová stabilní verze 23.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Stoat. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Příspěvek na blogu CZ.NIC upozorňuje na nový útok na weby v Česku. Na honeypotech na Turrisech byla zaznamenána nová aktivita útočníků - probíhající útok na FTP servery, které se vyskytují na stejné IP adrese, jako aktivní WEB server.
Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi 2023.05. Programovací jazyk Raku byl dříve znám pod názvem Perl 6.
Linux Foundation Europe představila projekt RISE (RISC-V Software Ecosystem), jehož cílem je urychlit vývoj open source softwaru pro architekturu RISC-V.
HTTP Error 403: The service you requested is restricted
The service you requested is restricted and not available to your browser
The restriction can be based on your IP-address, hostname, browser software, time-of-day or other variables. Most likely you requested a service that was made available to a restricted subnet.
Příklad takové stránky je třeba blog.cz
. Zkoušel jsem i traceroute a zdá se, že požadavek k serveru normálně dojde, pokud to správně chápu.
$ traceroute www.blog.cz
traceroute to blog.cz (217.31.54.174), 30 hops max, 40 byte packets
1 10.10.133.78 (10.10.133.78) 223.789 ms 249.924 ms 206.639 ms
2 10.10.133.66 (10.10.133.66) 626.631 ms 319.937 ms 199.988 ms
3 10.10.133.141 (10.10.133.141) 199.967 ms 249.935 ms 199.973 ms
4 10.10.133.1 (10.10.133.1) 206.635 ms 249.940 ms 749.965 ms
5 vl914.rcnR04i.oskarmobil.cz (217.77.160.26) 299.971 ms 199.924 ms 256.635 ms
6 po1-0.sitR00i.oskarmobil.cz (217.77.160.62) 199.969 ms 249.929 ms 416.637 ms
7 ge0-3.gtsR00i.oskarmobil.cz (217.77.160.18) 326.636 ms 226.600 ms 233.306 ms
8 nix-m.backbone.ignum.cz (194.50.100.8) 903.301 ms 343.262 ms 209.969 ms
9 chikuma.jyxo.com (217.31.54.174) 226.631 ms 223.266 ms 476.643 ms
Připojení je přes Vodafone Připojení na stálo do telefonu a přes bluetooth k počítači. Takhle to fungovalo několik měsíců. Vím, že mít připojený počítač přes mobilní internet je na nic, ale momentálně není jiná možnost.
Nevíte, prosím, v čem by mohl být problém? Případně rád poskytnu další informace.
Díky
Tak zkuste telnet na port 80 na daném serveru a uvidí se ... jak to maj vychytaný
$ telnet www.etree.org 80 Trying 152.46.7.81... Connected to etree.org. Escape character is '^]'.Vypadá to, že to takhle funguje u všech stránek co jsem zatím zkoušel, všechny i ty co jsem tu předtím vypisloval se po připojení rozběhly. Telnet to asi nějak prošťouchne. Ještě uvidím na jak dlouho. Napadá vás, co by šlo případně přes telnet zjistit? Nevím co do telnetu psát. Díky
GET / HTTP/1.0a stlacit 2x Enter; mal by si dostat nejaku odpoved zo servera.
GET / HTTP/1.0 Host: www.etree.orga 2× <Enter>, HTTP servery většinou používají virtual host a pokud nezadáte jméno, dostanete nějakou defaultní stránku (a proxy po cestě rozhodně nezjistí, kam se vlastně připojujete, takže nemůže nic filtrovat).
GET / HTTP/1.1 Host: www.etree.org Connection: closenakolko header field
Host
je definovany az protokolom HTTP 1.1.
HTTP/1.0
(a to Host
není), musí být u requestu uvedena verze HTTP/1.1
. Deklarací HTTP/1.1
totiž netvrdíte, že podporujete nebo používáte všechny jeho vymoženosti.
Request-Header field names can be extended reliably only in combination with a change in the protocol version. However, new or experimental header fields may be given the semantics of request header fields if all parties in the communication recognize them to be request header fields. Unrecognized header fields are treated as Entity-Header fields.Deklarací
HTTP/1.1
klient tvrdí, že je alespoň na minimální úrovni kompatibilní s HTTP 1.1 (což na klientské straně znamená např. povinnou hlavičku Host
). Jinak HTTP 1.1 vzniklo z velké části standardizací právě těch nových a experimentálních hlaviček HTTP 1.0, jako Host
nebo Connection
, takže se zákonitě musely používat hlavičky nedefinované v HTTP 1.0 před standardizací HTTP 1.1.
Ostatně protokol, který by nebyl dopředně kompatibilní a nepovoloval rozšíření, by byl celkem k ničemu – nebylo by možné jej prakticky rozvíjet a nové verze protokolu by nevycházely z praxe (co se používá), ale byla by to pouze teoretická práce (nikdo to nepoužívá, ale určitě by v protokolu chtěly tohle).
Tak si přečtěte ještě RFC 2145, sekci 2.3:
An HTTP client SHOULD send a request version equal to the highest version for which the client is at least conditionally compliant, and whose major version is no higher than the highest version supported by the server, if this is known. An HTTP client MUST NOT send a version for which it is not at least conditionally compliant.
An HTTP client MAY send a lower request version, if it is known that the server incorrectly implements the HTTP specification, but only after the client has determined that the server is actually buggy.
Host
, takže tam nemá co dělat.
Nová a experimentální? Devět let po RFC 2616 a jedenáct a půl roku po RFC 2068? To opravdu ani trochu nevypadá jako účelová konstrukce vymyšlená k obhájení neobhajitelného…
Mimochodem, docela by mne zajímalo, kolik z těch, kdo dnes lpí na HTTP/1.0, si je vědomo, jaký je časový odstup mezi RFC 1945 (specifikace HTTP/1.0) a RFC 2068 (první verze specifikace HTTP/1.1).
Mimochodem, docela by mne zajímalo, kolik z těch, kdo dnes lpí na HTTP/1.0, si je vědomo, jaký je časový odstup mezi RFC 1945 (specifikace HTTP/1.0) a RFC 2068 (první verze specifikace HTTP/1.1).Hlasim sa medzi tych, co by si priali, aby aspon fungovalo to http/1.0. Casovy rozdiel som nikdy neskumal. However, je vyrazne jednoduchsie implementovat prijatie http message tak, ze prijmem cely msg a az potom zacnem parsovat, zatial co persistent connections musim on-the-fly parsovat hlavicku, aby som zistil Content-Length. Uznavam, vo vseobecnosti nie je dobry pristup tahat cely msg do pamate (hehe, co ak je odpovedou DVD ISO image?), ale v specialnej aplikacii, ktoru som robil, toto nebolo issue. Zaroven nie je potrebne riesit 1xx status codes, a pod. Dost mi vsak liezlo na nervy, ked som jednemu velmi rozsirenemu open source browseru z pozicie http servera povedal, ze ovladam HTTP/1.0 a prajem si vypnute keep-alive a prosim ho o uzatvaranie spojenia po kazdom msg, a on mi napriek tomu cpal HTTP/1.1 requesty, pouzival http keep-alive, a spojenia zasadne neuzatvaral. Takze nelipnem striktne na http/1.0, ale ked je klient ci server on poziadany, mal by fungovat.
Host
rozhodit a maximálně ji bude ignorovat. Pokud by ji ignoroval, s HTTP 1.1 bych u něj asi neuspěl o nic lépe.
aby mohl "hyperkorektně" použít hlavičku Host
To hyper- je tam zcela nadbytečné, proč nenapíšete prostě jen korektně?
Pokud někdo uvede HTTP/1.1 tak tím tvrdí, že tento protokol ovládá, ale to při ruční komunikaci zpravidla není pravda
Smím se zeptat proč?
použít HTTP/1.0 a uvést hlavičku Host tam, protože vzhledem ke stáří HTTP/1.0 kterým se tu někdo oháněl je jasné, že sever to pochopí
Jasné to zdaleka není. A nejde tu ani tak o stáří HTTP/1.0, ale o to, že (1) první verze specifikace HTTP/1.1 vyšla před jedenácti a půl lety, takže to není nějaká horká novinka, které bychom se měli bát, a (2) mezi specifikací HTTP/1.0 a první verzí specifikace HTTP/1.1 uběhlo pouhých sedm měsíců a v samotném RFC 1945 je zmínka, že se očekává brzké nahrazení.
Ostatně protokol, který by nebyl dopředně kompatibilní a nepovoloval rozšíření, by byl celkem k ničemu – nebylo by možné jej prakticky rozvíjet a nové verze protokolu by nevycházely z praxe (co se používá), ...No, HTTP protokol je sice krasne otvoreny, dopredne kompatibilny a uzastne flexibilny, ale aj velmi nepresny, neuveritelne vagny a na niektorych miestach dokonca specifikacia odporuje sama sebe. Ak webdizajneri vedia, ze vebove prehliadace predstavuju "vitaztvo pocitaca nad clovekom", developeri webovych servero, proxy serverov a http klientov nie su na tom o nic lepsie. A vsetci, co sa zaoberaju bezpecnostou webovych aplikacii vedia, ze 95% bezpecnostnych problemov webovych applikacii suvisi prave s tym, ze ako prenosovy protokol je pouzite prave HTTP. Vsetky tri uvedene role som si mal tu moznost do sytosti vyskusat.
A vsetci, co sa zaoberaju bezpecnostou webovych aplikacii vedia, ze 95% bezpecnostnych problemov webovych applikacii suvisi prave s tym, ze ako prenosovy protokol je pouzite prave HTTP.To bych tedy těch 95 % chtěl vidět. Bezpečnostní problémy webových aplikací zpravidla znamenají ovlivnění serverové aplikace nebezpečným vstupem (např. SQL injection, PHP include apod.), další jsou pak problémy důvěryhodnosti dat v prohlížeči (XSS a různé další způsoby komunikace a kradení údajů mezi doménami). Nic z toho s HTTP nesouvisí. Další druh problému může být buffer overflow, ale to zase s HTTP nijak nesouvisí. Z hlediska bezpečnosti je nešťastný třeba pohrobek HTTP 1.0, kdy ukončení spojení ze strany serveru může být regulérní konec přenosu (místo aby bylo nutné vždy určovat délku entity).
HTTP/1.0 307 OK Location: http://a.redirect.info/blabla/(na stranku informujucu o povinnosti nastavit si DHCP; je tam formular, predvyplneny na nieco v zmysle "ano, rozumel som, nastavim si dhcp"; po jeho odoslani sa pripojenie obnovi. Nemohlo by to byt nieco podobne v Tvojom pripade?
http://www.blog.cz/ GET / HTTP/1.1 Host: www.blog.cz User-Agent: Mozilla/5.0 (X11; U; Linux i686; cs; rv:1.9) Gecko/2008052912 Firefox/3.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: cs,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive HTTP/1.x 403 not authorized Server: XMS (724Solutions HTA XMP_40_M1_B035 20080226.125455) Date: Mon, 30 Jun 2008 18:06:03 GMT Accept-Ranges: bytes Content-Type: text/html Content-Length: 1258 ----------------------------------------------------------Ale moc jsem z toho nevyčetl. Žádné přesměrování jako v tvém případě se nekoná. Prostě 403 a konec.
Server: XMS (724Solutions HTA XMP_40_M1_B035 20080226.125455)Jenže na blog.cz ve skutečnosti běží Apache. Právně znalí lidé, není tohle klasifikovatelné jako porušování listovního tajemství nebo tak něco?
Moj drahy provider v snahe zabranit pouzivaniu routerov v bytoch, forcuje pouzivanie DHCP; takze ak sa z ich pohladu koncove zariadenie nekonfiguruje pomocou DHCP, akykolvek http traffic presmeruju ...Jak se jim to daří? Vždyť i takový router umí DHCP (na jednom rozhraní klient, na druhém server). Dokud nerozbalí packet, tak nemůžou nic vědět (oni nemůžou nic vědět ani tak, protože virtualizační nástroje můžou taky dělat NAT).
traceroute --tcp --port=80 www.blog.cz
), implicitní je přes UDP, na což se HTTP filtry samozřejmě nechytají.
Mně se to stává taky, a to i na mobilu (Nokia E51 browser). Přes Operu Mini samozřejmě běhá všechno. A také je tento problém jen u Vodafonu Na stálo. Pomáhá jen odpojit se a znovu připojit, to změní IP adresu a skrytou stránku zpřístupní
Tiskni
Sdílej: