Linux за българи: Форуми

Програмиране => Web development => Темата е започната от: senser в Nov 08, 2010, 09:27


Титла: Проблем с РНР и fopen wrappers
Публикувано от: senser в Nov 08, 2010, 09:27
Здравейте,

Имам супер досаден проблем свързан с fopen wrappers - всички (или поне тези, които съм тествал) функции свързани с тях не работят. Ето един елементарен пример:
Код
GeSHi (PHP):
  1. $url='http://www.soapclient.com/xml/SQLDataSoap.WSDL';
  3. 	array('http'=>
  4. 		array('protocol_version'=> 1.0, 
  5. 			'ignore_errors' => true,
  6. 			'max_redirects'=>1)));
  7. $result=file_get_contents($url, false, $ctx);
  8.  
В резултат $result е празен стринг - не е false, РНР-то не връща никаква грешка, просто не прави изобщо рекуест към отдалечения ресурс (file_get_contents работи с локални файлове, но не и с файлове сервирани от локалното апаче). Същото важи и примерно за функции като get_headers() и fopen(), променлива като $http_response_header - все са празни. Всъщност няма и как да не са празни след като сървъра, към който е насочено питането изобщо не получава нищо (установено е ана апач, който е под мой контрол - никакъв GET или POST request не стига до него в резултат на РНР кода).
Чрез cURL или fsockopen и ръчно сетнати хедъри нещата работят, но това не е решение - трябва да преборя file_get_contents($remote_url).
Естествено в php.ini имам
Код:
allow_url_include = On
РНР-то е 5.3.3 билднато от сорс, но и с 5.2.х проблема е същия.
Някакви идеи?

Титла: Re: Проблем с РНР и fopen wrappers
Публикувано от: triel в Nov 08, 2010, 09:35
Погледни дали allow_url_fopen е "on".

Титла: Re: Проблем с РНР и fopen wrappers
Публикувано от: b2l в Nov 08, 2010, 10:23
Цитат на: triel в Nov 08, 2010, 09:35
Погледни дали allow_url_fopen е "on".

Стига бе, това е супер unsecurity...

Титла: Re: Проблем с РНР и fopen wrappers
Публикувано от: triel в Nov 08, 2010, 11:09
Цитат на: backtolife в Nov 08, 2010, 10:23
Стига бе, това е супер unsecurity...

Всъщност това, което senser е направил (а именно да позволи allow_url_include) е много по-голям проблем за сигурността. Ама наистина много.

От друга страна, той съвсем ясно е казал, че желае да ползва file_get_contents за remote files, така че единствената му опция е да позволи allow_url_fopen - независимо дали е secure, или не.

Титла: Re: Проблем с РНР и fopen wrappers
Публикувано от: Naka в Nov 08, 2010, 13:39
И защо allow_url_fopen да е unsecurity... Това е принципът на интернет - да се отварят URL-и. Пък било то локално или отдалечено, какво общо има. Ако някой иска да прави мизерии даже и при забранено allow_url_fopen, може да си отвори URL-а с Curl.

Когато се отваря URL по този начин не се сервира оригиналният source файл *.php например, а резултатът от изпълнението му, така че няма никакви проблеми.

тук писах за нещо подобно.
http://www.linux-bg.org/forum/index.php?topic=37789.0

говорите за две опции allow_url_include и allow_url_fopen.
allow_url_fopen трябва да е разрешено.

Титла: Re: Проблем с РНР и fopen wrappers
Публикувано от: b2l в Nov 08, 2010, 13:44
Цитат
If enabled, allow_url_fopen allows PHP's file functions -- such as file_get_contents() and the include and require statements -- can retrieve data from remote locations, like an FTP or web site. Programmers frequently forget this and don't do proper input filtering when passing user-provided data to these functions, opening them up to code injection vulnerabilities. A large number of code injection vulnerabilities reported in PHP-based web applications are caused by the combination of enabling allow_url_fopen and bad input filtering.

allow_url_fopen is on by default.

Recommendations

You should disable allow_url_fopen in the php.ini file:

; Disable allow_url_fopen for security reasons
allow_url_fopen = 'off'

Титла: Re: Проблем с РНР и fopen wrappers
Публикувано от: senser в Nov 08, 2010, 14:09
Съжалявам - грешката е моя. В php.ini имам
Код:
allow_url_fopen = On
а не
Код:
allow_url_include = On

Наистина няма смисъл да коментираме в момента сигурността - невъзможността да работя с fopen wrappers ми пречи в АПИ-тата, които ползвам и, които няма да тръгна да променям всичките, та нека видим на какво може да се дължи това. Ако представлява интерес може впоследствие да обясня какви точно са ми проблемите, но след доста дълбаене стигнах до извода, че РНР-то ми не може да отваря отдалечени ресурси и отттам се омазват много неща.

Титла: Re: Проблем с РНР и fopen wrappers
Публикувано от: Naka в Nov 08, 2010, 15:23
Това 'ignore_errors' => true, какво трябва да прави?
Спомням си че и аз имах много главоболия с file_get_contents. Докато го нагласиш да работи, пробвай винаги да си разпечатваш $http_response_header.

Титла: Re: Проблем с РНР и fopen wrappers
Публикувано от: senser в Nov 08, 2010, 16:27
Цитат на: Naka в Nov 08, 2010, 15:23
Това 'ignore_errors' => true, какво трябва да прави?
Спомням си че и аз имах много главоболия с file_get_contents. Докато го нагласиш да работи, пробвай винаги да си разпечатваш $http_response_header.
ignore_errors прави това, което се очаква - при възникване на грешка я игнорва и продължава, но това не е проблем. С или без този параметър функцията не работи.
Аз досега никога не съм имал проблем с file_get_contents - винаги е работел както съм очаквал - подозирам, че при мен нещо РНР-то не е ОК, но пък и няколко версии компилирах вече и няма разлика .........
Както казах вече, масива $http_response_header винаги е празен просто, защото request до отдалечената страна изобщо не стига.

Титла: Re: Проблем с РНР и fopen wrappers
Публикувано от: triel в Nov 08, 2010, 16:56
Някакви fancy firewall rules, забраняващи изходящи връзки на потребителя, който е стартирал PHP скрипта?

Титла: Re: Проблем с РНР и fopen wrappers
Публикувано от: senser в Nov 08, 2010, 17:04
Цитат на: triel в Nov 08, 2010, 16:56
Някакви fancy firewall rules, забраняващи изходящи връзки на потребителя, който е стартирал PHP скрипта?
Не мисля. Апача с РНР-то работи на лаптопа ми, който ползвам за работа, а той през ВИФИ е в нета. Пробвах и забучих директно кабела в лаптопа, заобикаляйки OpenWRT- to и евентуално някой iptables rule, но положението е същото.
Обърни внимание, че дори и да опитам нещо като file_get_contents('http://localhost/test') пак фейлва. А в апача изобщо не се вижда някой да се опитва да достъпи /test.
Не е от това според мен.

Титла: Re: Проблем с РНР и fopen wrappers
Публикувано от: Naka в Nov 08, 2010, 17:12
Когато тествах с file_get_contents, симулирах разпаднала връзка като откачаx кабела - тогава file_get_contents връщаше false и $http_response_header беше празен.

затова те питах за ignore_errors => true предполагам че като е ignore_errors => false, file_get_contents вече няма да връща празен стринг а ще започне да връща false.

Т.е и аз си мисля че нещо пречи на изходящият трафик.

Титла: Re: Проблем с РНР и fopen wrappers
Публикувано от: senser в Nov 08, 2010, 17:57
Цитат на: Naka в Nov 08, 2010, 17:12
Когато тествах с file_get_contents, симулирах разпаднала връзка като откачаx кабела - тогава file_get_contents връщаше false и $http_response_header беше празен.

затова те питах за ignore_errors => true предполагам че като е ignore_errors => false, file_get_contents вече няма да връща празен стринг а ще започне да връща false.

Т.е и аз си мисля че нещо пречи на изходящият трафик.

Промяната на този параметър не променя по никакъв начин нещата. Без изобщо да сетвам stream context пак е същото. На другите машини никъде не съм го сетвал даже, просто в момента се мъча по някакъв начин да разбера къде може да е проблема и затова има stream_context_create

Титла: Re: Проблем с РНР и fopen wrappers
Публикувано от: d0ni в Nov 08, 2010, 19:40
ако си с линукс защо не извикаш php файла през CLI и да го strace-неш, така има голяма вероятност да видиш къде е проблемът.

Титла: Re: Проблем с РНР и fopen wrappers
Публикувано от: senser в Nov 08, 2010, 20:01
Цитат на: d0ni в Nov 08, 2010, 19:40
ако си с линукс защо не извикаш php файла през CLI и да го strace-неш, така има голяма вероятност да видиш къде е проблемът.
Нямам инсталиран strace,  но го пуснах през gdb и си мина нормално - без грешки и file_get_contents пак връща празен стринг. Според мен проблема не е в бъг на РНР-то, а по-скоро някаква сбъркана конфигурация или знам ли и аз вече ...........

Ето phpinfo(): http://senser.no-ip.org/phpinfo.php ($2)

П.П. След малко ще го пусна и през strace и ще дам резултат

Титла: Re: Проблем с РНР и fopen wrappers
Публикувано от: neter в Nov 08, 2010, 22:56
Цитат на: senser в Nov 08, 2010, 09:27
file_get_contents работи с локални файлове, но не и с файлове сервирани от локалното апаче
Какво точно имаш предвид с това? Първоначално реших, че става дума, че проблемът не се проявява, когато изпълниш кода през CLI (демек, в конзолата), а се проявява само когато изпълниш кода през браузъра, но в последния си пост казваш, че и през CLI получаваш празен стринг. Какво точно е положението с проблема, когато кодът се изпълни през браузъра и през CLI?
И как проверяваш дали $result е празен или false? Така
Код
GeSHi (PHP):
  1. if ($result === false)
  2.     echo 'Is false';
или по друг начин?

Титла: Re: Проблем с РНР и fopen wrappers
Публикувано от: senser в Nov 09, 2010, 07:03
Цитат на: neter в Nov 08, 2010, 22:56
Какво точно имаш предвид с това? Първоначално реших, че става дума, че проблемът не се проявява, когато изпълниш кода през CLI (демек, в конзолата), а се проявява само когато изпълниш кода през браузъра, но в последния си пост казваш, че и през CLI получаваш празен стринг. Какво точно е положението с проблема, когато кодът се изпълни през браузъра и през CLI?
Не бях пробвал през CLI, до предложението на д0ни. Имах впредвид, че
Код
GeSHi (PHP):
  1. file_get_contents('/path/to/local/file')
  2.  
работи, но ако се опитам да достъпя същия файл през апача и не работи:
Код
GeSHi (PHP):
  1. file_get_contents('http://localhost/path/to/file')
  2.  
Файла разбира се го слагам в webroot и през браузър си е достъпен.

Цитат на: neter в Nov 08, 2010, 22:56
И как проверяваш дали $result е празен или false? Така
Код
GeSHi (PHP):
  1. if ($result === false)
  2.     echo 'Is false';
или по друг начин?

Точно - ето snippet:
Код
GeSHi (PHP):
  1. <?php
  2. $url='http://46.10.18.2/';
  3. $result=file_get_contents($url);
  4. if($result===false){ print 'Is false'; }
  5. else{ print '<pre>';var_dump($result);print '</pre>'; }
  6.  
, който код връща това:
Код:
string(0) ""

Резултата от изпълнението през CLI в strace обаче тотално ме разби. Пуснах го да се изпълни около 10 пъти, като в 3 от тях file_get_contents върна празен стринг, а в 7 успя да вземе отдалечената страница. Ето отрязък от изхода на strace, когато върна празен стринг:
Код:
close(4)                                = 0
munmap(0x7f0fd0472000, 4096)            = 0
write(1, "<pre>", 5)                    = 5
write(1, "http://46.10.18.2/", 18)      = 18
write(1, "</pre>", 6)                   = 6
clock_gettime(CLOCK_MONOTONIC, {279797, 367838193}) = 0
clock_gettime(CLOCK_MONOTONIC, {279797, 367908864}) = 0
clock_gettime(CLOCK_MONOTONIC, {279797, 367969758}) = 0
clock_gettime(CLOCK_MONOTONIC, {279797, 368023948}) = 0
clock_gettime(CLOCK_MONOTONIC, {279797, 368077579}) = 0
clone(child_stack=0x7f0fc633cff0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f0fc633d9e0, tls=0x7f0fc633d710, child_tidptr=0x7f0fc633d9e0) = 27152
clock_gettime(CLOCK_MONOTONIC, {279797, 368280651}) = 0
clock_gettime(CLOCK_MONOTONIC, {279797, 368336797}) = 0
clock_gettime(CLOCK_MONOTONIC, {279797, 368389031}) = 0
clock_gettime(CLOCK_MONOTONIC, {279797, 368438752}) = 0
clock_gettime(CLOCK_MONOTONIC, {279797, 368729534}) = 0
clock_gettime(CLOCK_MONOTONIC, {279797, 369055512}) = 0
clock_gettime(CLOCK_MONOTONIC, {279797, 369106070}) = 0
clock_gettime(CLOCK_MONOTONIC, {279797, 369154953}) = 0
clock_gettime(CLOCK_MONOTONIC, {279797, 369210260}) = 0
clock_gettime(CLOCK_MONOTONIC, {279797, 369258864}) = 0
clock_gettime(CLOCK_MONOTONIC, {279797, 369307467}) = 0
clock_gettime(CLOCK_MONOTONIC, {279797, 369355512}) = 0
clock_gettime(CLOCK_MONOTONIC, {279797, 369425344}) = 0
futex(0x7f0fc633d9e0, FUTEX_WAIT, 27152, NULL) = 0
write(1, "string(0) \"", 11)            = 11
write(1, "\"\n", 2)                     = 2
munmap(0x7f0fd032b000, 528384)          = 0
close(2)                                = 0
close(1)                                = 0
munmap(0x7f0fd0329000, 4096)            = 0
close(0)                                = 0
munmap(0x7f0fd032a000, 4096)            = 0
munmap(0x7f0fc6548000, 2185624)         = 0
munmap(0x7f0fc675e000, 2109872)         = 0
munmap(0x7f0fc6962000, 2105696)         = 0
munmap(0x7f0fc6b65000, 2114048)         = 0
munmap(0x7f0fc6d6a000, 2142984)         = 0
munmap(0x7f0fc6f76000, 2435864)         = 0
munmap(0x7f0fc7493000, 2130688)         = 0
munmap(0x7f0fc71c9000, 2924352)         = 0
munmap(0x7f0fc7e85000, 2118144)         = 0
munmap(0x7f0fc7bc6000, 2875640)         = 0
munmap(0x7f0fc78b3000, 3219512)         = 0
munmap(0x7f0fc808b000, 2127056)         = 0
munmap(0x7f0fc8293000, 2126528)         = 0
gettimeofday({1289239084, 346413}, NULL) = 0
munmap(0x7f0fc849b000, 2253992)         = 0
munmap(0x7f0fc8a61000, 2155560)         = 0
exit_group(0)                           = ?

и така свършва изпълнениеот.
Ето и отрязък при успешното изпълнение на file_get_contents:

Код:
close(4)                                = 0
munmap(0x7f17211c6000, 4096)            = 0
write(1, "<pre>", 5)                    = 5
write(1, "http://46.10.18.2/", 18)      = 18
write(1, "</pre>", 6)                   = 6
clock_gettime(CLOCK_MONOTONIC, {279823, 109987076}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 110055791}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 110115847}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 110169478}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 110222830}) = 0
clone(child_stack=0x7f1717090ff0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f17170919e0, tls=0x7f1717091710, child_tidptr=0x7f17170919e0) = 27158
clock_gettime(CLOCK_MONOTONIC, {279823, 110708584}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 110766685}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 110819199}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 110868081}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 110941824}) = 0
gettimeofday({1289239110, 81599}, NULL) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 111056349}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 111108305}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 111158863}) = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
fcntl(4, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
connect(4, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("46.10.18.2")}, 16) = -1 EINPROGRESS (Operation now in progress)
poll([{fd=4, events=POLLOUT|POLLWRNORM}], 1, 0) = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, {279823, 111599925}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 111677858}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 111726182}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 111777020}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 111824785}) = 0
poll([{fd=4, events=POLLOUT|POLLWRNORM}], 1, 0) = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, {279823, 111923109}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 111971992}) = 0
select(5, [], [4], [], {15, 0})         = 1 (out [4], left {14, 456708})
clock_gettime(CLOCK_MONOTONIC, {279823, 655820316}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 655923389}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 656018361}) = 0
poll([{fd=4, events=POLLOUT|POLLWRNORM}], 1, 0) = 1 ([{fd=4, revents=POLLOUT|POLLWRNORM}])
clock_gettime(CLOCK_MONOTONIC, {279823, 656299646}) = 0
getsockopt(4, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 656520875}) = 0
getpeername(4, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("46.10.18.2")}, [16]) = 0
getsockname(4, {sa_family=AF_INET, sin_port=htons(41367), sin_addr=inet_addr("10.10.10.10")}, [16]) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 656873947}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 656982327}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 657085958}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 657192942}) = 0
sendto(4, "GET / HTTP/1.1\r\nUser-Agent: Mozi"..., 74, MSG_NOSIGNAL, NULL, 0) = 74
clock_gettime(CLOCK_MONOTONIC, {279823, 657555512}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 657686517}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 657787355}) = 0
poll([{fd=4, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, {279823, 657993500}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 658152439}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 658259702}) = 0
select(5, [4], [4], [], {15, 0})        = 1 (out [4], left {14, 999993})
clock_gettime(CLOCK_MONOTONIC, {279823, 658508584}) = 0
poll([{fd=4, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, {279823, 658707467}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 658803277}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 658902439}) = 0
select(5, [4], [4], [], {15, 0})        = 1 (out [4], left {14, 999995})
clock_gettime(CLOCK_MONOTONIC, {279823, 659145177}) = 0
poll([{fd=4, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, {279823, 659343780}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 659439590}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 659539031}) = 0
select(5, [4], [4], [], {15, 0})        = 1 (out [4], left {14, 999995})
clock_gettime(CLOCK_MONOTONIC, {279823, 659773109}) = 0
poll([{fd=4, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, {279823, 659970595}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 660066126}) = 0
clock_gettime(CLOCK_MONOTONIC, {279823, 660174227}) = 0
select(5, [4], [4], [], {15, 0})        = 1 (out [4], left {14, 999995})
clock_gettime(CLOCK_MONOTONIC, {279823, 660408026}) = 0
poll([{fd=4, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, {279823, 660605512}) = 0
Като тук има доста изход от strace до приключване на изпълнението.

Ето ги двата пълни strace-a:
При празен стринг: http://senser.no-ip.org/strace ($2)
При непразен стринг: http://senser.no-ip.org/strace2 ($2)


Титла: Re: Проблем с РНР и fopen wrappers
Публикувано от: Naka в Nov 09, 2010, 13:06
Цитат
Пуснах го да се изпълни около 10 пъти, като в 3 от тях file_get_contents върна празен стринг, а в 7 успя да вземе отдалечената страница.

Има нещо гнило в начина по който file_get_contents работи.
Някакво кеширане ...

Има опции за timeout и за socket_timeout. http://bg2.php.net/manual/en/context.http.php
Спомням си че ги задавах.... Но въпреки че ги задавах големи стойности - един път при грешка(откачен кабел) file_get_contents връщаше разултата за 4 секунди, а друг път изчакваше 60 сек. точно колкото съм задал timeout/default_socket_timeout времето.

Обаче като един път върне резултат за  4 секунди след това винаги връщаше резултата пак за 4 секунди, незвисимо какво правя. Оправяше се след рестарт на apache-то. ??? ??? ???

Много ми е интересно какъв точно ще се окаже проблема.

---------------------------------------
Казваш че ти е трудно да променяш всички апи-та. Защо не си направиш една функция например my_file_get_contents() със обсолютно същите параметри като file_get_contents().

Вътре в my_file_get_contents() пишеш само да връща  резултата от  file_get_contents() или пък в my_file_get_contents() си правиш емулация с CURL. Така винаги можеш да промяняш и да експериментираш начина по който my_file_get_contents() работи.

А пък за сменянето на всички апи-та съм го правил така.
с кате "find и replace"  file_get_contents -> my_file_get_contents ги сменяш всичките.

да намериш всички файлове от където се извиква file_get_contents

Код:
find -name "*.php" -exec grep --with-filename --line-number -i "file_get_contents" {} \;





Титла: Re: Проблем с РНР и fopen wrappers
Публикувано от: senser в Nov 09, 2010, 13:20
Цитат на: Naka в Nov 09, 2010, 13:06
Цитат
Пуснах го да се изпълни около 10 пъти, като в 3 от тях file_get_contents върна празен стринг, а в 7 успя да вземе отдалечената страница.
Вкарах го в един цикъл и през CLI около 5-10% от опитите минават.
Същото е и през браузър горе-долу.

Цитат на: Naka в Nov 09, 2010, 13:06
Има опции за timeout и за socket_timeout. http://bg2.php.net/manual/en/context.http.php
Спомням си че ги задавах.... Но въпреки че ги задавах големи стойности - един път при грешка(откачен кабел) file_get_contents връщаше разултата за 4 секунди, а друг път изчакваше 60 сек. точно колкото съм задал timeout/default_socket_timeout времето.

В някои от всичките ми тестове мисля, че минах и през тези опции без успех, но пак ще ги пробвам.


Powered by SMF 2.0 Beta 4 | SMF © 2006, Simple Machines LLC