Pozor na Yahoo! Slurp, vyžírá linku zbytečnými přenosy (diskuse)

[Jendа]

Kdyby někoho zajímalo, ze kterých IP tam ten robot lezl:

67.195.111.154
67.195.111.186
67.195.112.43
67.195.112.48
67.195.115.121
67.195.115.53
67.195.115.55
67.195.115.87
67.195.37.187
72.30.142.215

[xkomczax]

A lidi v Yahoo to neštve? Přeci jenom, při představě, kolik dat musí stáhnout prolézá-li celý web... Co takto napsat někomu přímo do Yahoo, nemělo by to smysl?

[otasomil]

Dival jsem se na Vas osobni web a tak se ptam jak jste spokojen s hostingem od http://www.000webhost.com/

Zda vyuzivate free variantu a nebo jste neco priplatil za sluzby navic.

 

Kdysi jsem se zminoval v blogu o tomto poskytovateli.

[Alexandra Pokorná]

Přestože nejsem autorkou předchozího komentáře 000webhost jsem zkoušela. Severy byly docela pomalé a docházelo k častým výpadkům a to především databáze, která často nešla i několik hodin. Dost závisí na jaký server Vás posadí. Pro Evropanku jako já je téměř dokonalý, protože hodiny nejvyššího zatížení webů ve SSA se liší od těch našich a tak nemohu než doporučit.

[xkomczax]

O blogu vím, z něj jsem se taky k 000webhost.com dostal Takže alespoň dodatečně díky za ten zápis
Používám free variantu a jsem s ní... no... vzhledem k tomu, že nic lepšího neznám, tak spokojen Ale jak již psala Alexandra Pokorná přede mnou, s rychlostí to není nic moc extra. Jak kdysi napsal jistý člověk, kterému jsem tam uložil jeden soubor: "Chovalo se to, jako by server byl za ADSL a dvěma WiFinami " (doufám, že tomu dotyčnému zveřejnění této části mailu nevadí...). Výpadky občas bývají, to je pravda, ale nevidím to s nimi nikterak černě.
Co mne tak trochu mrzí, tak je nabídka v jejich administračním rozhraní, která toho na první pohled slibuje hodně, ale polovina věcí (dobře, tak méně než polovina, ale...) nefunguje. Konkrétně instalace přes Fantastico Autoinstaller a statistiky. Takže shrnutí: není to nic moc extra, ale na těch mých pár fotek a nějakou tu statickou webovku je to myslím až moc dobré Ale pokud by jsi věděl (doufám, že tykání nevadí, pokud ano, tak se omlouvám...) o něčem lepším, tak sem s tím!
A mimochodem, proč se ptáš? Zjišťuješ, zda-li to nefunguje na 100% jenom Tobě či zda-li s tím mají problémy i ostatní nebo máš návrh na nějakou lepší službu? Či jenom tak se ptáš? Já jen že mne ta otázka dost překvapila, pokud nechceš, nemusíš odpovídat...

[Jendа]

A lidi v Yahoo to neštve? Přeci jenom, při představě, kolik dat musí stáhnout prolézá-li celý web...

Také mi to přišlo fascinující. Mimochodem, má-li tu někdo nějaký podobný web (balíčky, video, audio) a loguje, kouknul by se, jestli tohle postihlo selektivně vpsFree, nebo je to i jinde? Zkusím se ještě zeptat adminů z mirroru na ČVUT, jestli si něčeho takového také nevšimli.

Co takto napsat někomu přímo do Yahoo, nemělo by to smysl?

Jo, dobrý nápad, o něčem porozmýšlím. Jinak podobné problémy očividně mají i tady a tady (co jsem tak rychle vygooglil).

[Jendа]

Zkusím se ještě zeptat adminů z mirroru na ČVUT, jestli si něčeho takového také nevšimli.

Tak ze Silicon Hill Mirroru také stahuje, a to velmi - kolem 8000 requestů za den. Povšimněte si, prosím, že stahuje, i když jejich server normálně posílá ETag, Last-Modified i Age.

Překládám ftp.sh.cvut.cz… 147.32.127.222, 2001:718:2::222
Navazuje se spojení s ftp.sh.cvut.cz|147.32.127.222|:80… spojeno.
HTTP požadavek odeslán, program čeká na odpověď… 
  HTTP/1.0 200 OK
  Date: Sat, 19 Feb 2011 08:16:20 GMT
  Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny9 with Suhosin-Patch
  Last-Modified: Mon, 22 Nov 2010 11:53:15 GMT
  ETag: "1033-2bc9b800-495a2e6b980c0"
  Accept-Ranges: bytes
  Content-Length: 734640128
  Content-Type: application/x-iso9660-image
  Age: 45834
  X-Cache: HIT from ftp.sh.cvut.cz
  X-Cache-Lookup: HIT from ftp.sh.cvut.cz:80
  Via: 1.1 ftp.sh.cvut.cz:80 (squid)
  Connection: keep-alive
Délka: 734640128 (701M) [application/x-iso9660-image]

[Filip Jirsák]

Jak vypadá druhý požadavek od toho robota? V něm nejsou hlavičky If-Modified-Since nebo If-Match? Pokud tam jsou, a server stejně pošle celý soubor, je to chyba serveru.

[Jendа]

To bohužel nevím, protože admin mirroru na SH mi ukázal jenom tenhle a mě ještě od zapnutí logování kompletních požadavků robot nenavštívil. Nicméně například na jiném webu, kam už robot přišel, to vypadalo takhle:

2011-02-19 22:15:11: (request.c.294) fd: 9 request-len: 309 
GET /styl.css HTTP/1.0
Host: blok.hrach.eu
User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)
Accept: text/css,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Referer: http://blok.hrach.eu/

Na což server samozřejmě odpoví 200 a pošle celý styl.

[Filip Jirsák]

Řekl bych, že to lidi z Yahoo štve. Ale co s tím mají dělat – psát každému, kdo má blbě nastavený web server? Nebo implementovat křišťálovou kouli, ze které vyvěští ty informace, které zapomněl nastavit správce webu?

[pavlix]

Kdybyste místo těch vašich obvyklých žvástu uvedl nějakou skutečnou informaci, udělal byste líp.

[kik]

Nezjišťují náhodou, jestli nepřechováváš to ošklivé "kindr pr0n"?

[kik]

"k!ndr"

[SPM]

Napsat abuse :)) Jinak jsem se koukal do access logu svýho apache, kde je těch pár .deb balíčků... z těhlech rozsahů je tahá něco taky, ikdyž naposled to bylo 14. takže asi ne tak často

[GeoRW]

ja na download odkazy pouzivam atribut rel="nofollow" odkedy mi podobne robil aj Google crawler (aj ked to boli .zip subory); odvtedy ziaden problem so ziadnym crawlerom

[Jiří Němec]

Co takhle zkontrolovat jestli ten hosting správně posílá etagy? Jestli když sedí, tak pošle jen 304 a neposílá data? Je tam správně definovaný datum expirace? Nedaří se mi dostat z YSlow ani z Page Speed informace přímo o těch videích, ale zbytek webu stále posílá 200 i veškerý obsah i když nedošlo k žádné změně obsahu. Čas expirace tam není nastaven.

[Jendа]

304 si robot nechal poslat jenom několikrát.

::ffff:67.195.115.55 video.hrach.eu - [18/Jun/2010:01:10:49 +0200] "GET /video/vasut1.ogg HTTP/1.0" 304 0 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)"
::ffff:67.195.115.55 video.hrach.eu - [31/May/2010:17:01:29 +0200] "GET /video/scf10/scf-uvod.ogg HTTP/1.0" 304 0 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)"
::ffff:67.195.112.43 video.hrach.eu - [26/May/2010:17:29:31 +0200] "GET /video/vasut2.ogg HTTP/1.0" 304 0 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)"
::ffff:67.195.112.43 video.hrach.eu - [27/May/2010:02:56:06 +0200] "GET /video/vasut2.ogg HTTP/1.0" 304 0 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)"
::ffff:72.30.142.215 video.hrach.eu - [19/Nov/2010:17:42:27 +0100] "GET /video/vasut1.ogg HTTP/1.0" 304 0 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)"
::ffff:72.30.142.215 video.hrach.eu - [20/Nov/2010:02:06:21 +0100] "GET /video/scf10/malec-elektronicke-pasy.ogg HTTP/1.0" 304 0 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)"
::ffff:72.30.142.215 video.hrach.eu - [20/Nov/2010:15:56:26 +0100] "GET /video/vasut2.ogg HTTP/1.0" 304 0 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)"
::ffff:67.195.115.121 video.hrach.eu - [22/Nov/2010:11:11:03 +0100] "GET /video/vasut2.ogg HTTP/1.0" 304 0 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)"
::ffff:67.195.115.121 video.hrach.eu - [19/Dec/2010:04:27:05 +0100] "GET /video/scf10/soufflot-access-for-enterprise.webm HTTP/1.0" 304 0 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)"

Etagy jsem zapnul (díky za tip), v lighttpd byly defaultně vypnuté.

[gtz]

U Yahoo i u Google tohle bylo zcela normální, že se snažil indexovat to co je na webu. Nakonec se tyto služby zakázaly na firewallu a byl pokoj.

[Jendа]

Ne, GoogleBot i SeznamBot stáhnou vždycky jenom začátek souboru, a když zjistí, že tento obsah nechtějí, už ho znova netahají. Opakovaně tahá celý soubor jenom Yahoo.

[Josef Kufner]

Napiš do /robots.txt patřičná pravidla a budeš mít pokoj.

[Jendа]

No to jsem už udělal. Píšu o tom hlavně proto, že mě nenapadlo, že by takový problém mohl nastat, a třeba tím někomu dalšímu ušetřím zahraniční konektivitu.

[pc2005]

Hmmm zajímalo by mě kolik threadů dokáže ten robot spustit. Nechcete někdo exportovat /dev/urandom ?

[Filip Jirsák]

To je jak zprávy rádia Jerevan.

Když váš server nedokáže správně odpovědět na hlavičky If-Modified-Since nebo If-Match (na tu odpovědět nemůže, když ani neposílá E-tag), nemá klient jinou možnost, jak zjistit, zda nedošlo ke změně, než stáhnout celý soubor znova.

Pokud chcete robotům zakázat stahování nějaký souborů použijte /robots.txt.

Zakazování přístupu robotům na firewallu je nesmysl, robot může za chvíli chodit z jiné adresy, nebo přijde jiný robot. A hlavně ten robot nedělá nic špatného, chyba (a ne jedna) je jen na vaší straně.

[pavlix]

Když váš server nedokáže správně odpovědět na hlavičky If-Modified-Since nebo If-Match (na tu odpovědět nemůže, když ani neposílá E-tag), nemá klient jinou možnost, jak zjistit, zda nedošlo ke změně, než stáhnout celý soubor znova.

A, tak přecejenom, teď už můžete s klidem zapomenout, co jsem napsal k vašemu předchozímu příspěvku.

[Jendа]

Když váš server nedokáže správně odpovědět na hlavičky If-Modified-Since

V některých případech (*.webm) skutečně nedokázal, bug, opraveno (děkuju za upozornění). Ale Slurp vesele stahoval i všechno ostatní, kde se tahle hlavička posílala - Slurp totiž do požadavku hlavičku If-Modified-Since vůbec nevkládá.

nebo If-Match (na tu odpovědět nemůže, když ani neposílá E-tag)

No, to je pravda, nechápu, proč to bylo ve výchozím nastavení vypnuté.

nemá klient jinou možnost, jak zjistit, zda nedošlo ke změně, než stáhnout celý soubor znova

Koukám, že lighttpd je v tomhle pěkně rozbitý software (klidně vnutí klientovi typ souboru, který si nevyžádal v Accept, místo aby hodil 406), ale - opět - stejně bych si nepomohl, Slurp posílá v Accept i *. Podle mě by bylo mnohem vhodnější, kdyby si skutečně vyžádal jenom ty typy souborů, které indexuje.

Pokud chcete robotům zakázat stahování nějaký souborů použijte /robots.txt.

To jsem hned udělal, čekám, až si ten soubor znovu vyžádá (na mirroru Archlinuxu už to udělal a už to celé nestahuje).

Zakazování přístupu robotům na firewallu je nesmysl, robot může za chvíli chodit z jiné adresy, nebo přijde jiný robot.

Jasně, to mělo být dočasné řešení, protože o robots.txt žádá jenom občas (teď koukám do logu, že tak obden).

Doufám, že tenhle zápisek a váš komentář alespoň někomu pomůže.

[Filip Jirsák]

Ale Slurp vesele stahoval i všechno ostatní, kde se tahle hlavička posílala - Slurp totiž do požadavku hlavičku If-Modified-Since vůbec nevkládá.

Vzhledem k tomu, že váš server posílá aktuální datum a čas, by ta hlavička stejně byla k ničemu.

Podle mě by bylo mnohem vhodnější, kdyby si skutečně vyžádal jenom ty typy souborů, které indexuje.

Jste si jistý tím, že videa nijak neindexuje? Vyhledávače se snaží zaindexovat všechno, typ souboru budou nejspíš brát jenom jako pomocné kritérium. Pokud chcete indexování omezit, použijte robots.txt, zbytek bych nechal na vyhledávači – jestli si myslí, že si poradí s videem, tak ať si ho klidně stáhne.

[Jendа]

Vzhledem k tomu, že váš server posílá aktuální datum a čas, by ta hlavička stejně byla k ničemu.

Kde? Nikde to tam nevidím.

--2011-02-19 23:38:06--  http://mirror.vpsfree.cz/archlinux/iso/latest/archlinux-2010.05-core-dual.iso
Překládám mirror.vpsfree.cz… 83.167.228.98, 2a01:430:17:1::60
Navazuje se spojení s mirror.vpsfree.cz|83.167.228.98|:80… spojeno.
HTTP požadavek odeslán, program čeká na odpověď…
  HTTP/1.0 200 OK
  Connection: keep-alive
  Content-Type: application/x-iso9660-image
  Accept-Ranges: bytes
  ETag: "1691149564"
  Last-Modified: Sun, 16 May 2010 14:30:16 GMT
  Content-Length: 691011584
  Date: Sat, 19 Feb 2011 22:38:06 GMT
  Server: lighttpd/1.4.19

A když mu pošlu třeba If-modified-since: Fri, 18 Feb 2011 15:00:00 GMT, vrátí 304.

[Filip Jirsák]

Zkoušel jsem to na těch adresách video.hrach.eu. Tam server neposílal ani ETag ani Last-Modified, jenom čas zpracování požadavku v hlavičce Date.

[Jendа]

Podle mě neposílal Last-Modified jen u souborů, u kterých neznal mime typ (tj. webm a mkv, vizte bug výše) a u dynamicky generovaného HTML (tj. index.php s různými parametry), ale teď už to těžko zjistíme. Ale ETagy se to spravilo, robot mi už posílá hlavičky typu If-None-Match: "29492511", takže mu můžu odpovídat 304. Takže uznávám, že chyba byla u mě, doplním řešení do zápisku.

Stejně mi ale přijde zajímavé, že se někomu vyplatí provozovat robota, který stahuje úplně všechno - když si vezmete, kolik existuje po světě zrcadel různých distribucí, každé o velikosti stovek GB, a spousta jich toto nemá zakázané v robots.txt, tak i když jejich servery mají správně nastavené cachování, robot se musí ustahovat.

[Filip Jirsák]

Myslím, že většina profi mirrorů to bude mít nastaveno správně. A ti ostatní si to holt nastaví správně po podobné zkušenosti, jakou máte vy Celkem chápu, že robot stahuje všechno – spousta serverů je špatně nakonfigurovaná, takže vrací třeba špatný mimetyp, dále jsou to chybné informace o kódování stránky nebo o jazyce… Robot, který by moc spoléhal na informace od uživatele, by spoustu věcí vůbec nenašel. Takže raději stahuje všechno a pak se v tom pokouší sám vyznat.