Как узнать полный путь для открытого удаленного файла ?

[sergep]

Как узнать полный путь для открытого удаленного файла ?

Суть проблемы, сайт может открывать удаленные файлы (www страницы) с помощью fopen.
Если для открытия предлагается пользователем именно файл - урл проверяется (по расширению, например zip), и выдается сообщение, что это файл и он не может быть загружен.
Однако на многих сайтах ссылки на файлы скрываются, а при вызове подобной ссылки удаленный сервер - кидает перенаправление на реальный урл. Проблема в том, что fopen это перенаправление легко автоматом обрабатывает и начинает открывать предложенный ему реальный урл, т.е. файл в чистом виде.

Как можно после открытия файла проверить что на самом деле открыл fopen ? Или до того как-то выловить урл на который удаленный сервер перенаправит.
Файловый дескриптор - только число. Где хранятся данные об открытом файле (его урл) не нашел.

Может можно как то иначе решить проблему ?

PHP Version 4.4.0 Денвер

 

[kruglov]

[m]fsockopen[/m] и вручную.

 

[Фанат]

Где хранятся данные об открытом файле (его урл) не нашел.

и не найдёшь.
поскольку никакого урла среди данных о файле нет, и быть не может.
у файла есть размер, время создания, номера кластеров на диске, которые он занимает.
а урла - нет.
файл можно открыть только на диске.
а урл - это заголовок в протоколе НТТР.
и вот когда ты поймёшь, что у тебя не файл, а заголовок, то сразу поймёшь, что тебе делать и где искать

 

[sergep]

kruglov, fsockopen я смотрел, но думаю что если даже возможно написать полностью функцию обмена с сервером то это всё равно слишком сложно

хотя надо попробовать, возможно это и не так сложно как кажется

а что значит вручную ?

Фанат, я понимаю что у меня не файл, и что у меня заголовок, но я понимаю, что если я в функцию передаю урл, то он как то где промежуточно сохраняется, и соответственно если удаленный сервер перенаправил fopen на новый урл то по идее этот новый урл должен же где то храниться ?
Или я что-то не понимаю ? Где искать ?

 

[Фанат]

где искать, тебе написал kruglov

 

[sergep]

значит только с помощью fsockopen запрашивать файл и вылавливать в ответе - "Hyper Text Continuation: Location: ..." ?

проще пути точно нет ? никаких системных переменных для файлового дескриптора, откуда бы можно было вытянуть информацию для открытого удаленного файла ?

 

[Фанат]

нету никаких удалённых файлов
и открываешь ты не файл.
У ФАЙЛОВ НЕ БЫВАЕТ УРЛОВ

 

[sergep]

ну если я открываю http://www.zzz.ru/index.html - то это возможно и неправильно назвать файлом, пусть это будет "документ с удаленной машины" (как написано в одном из учебников)
но если это http://www.zzz.ru/zzz.zip
почему это не файл ? и урл у него есть
и запрашиваю я именно fopen ("http://www.zzz.ru/zzz.zip", "r");

я не улавливаю в чем проблема
проблема в терминах ?

понятно что php явно считает что http://www.zzz.ru/zzz.zip это не путь а просто некая строка которую он должен кинуть в Hyper Text: GET

пусть так, пусть это не урл и не путь, но все равно эта строка подается в fopen как некий специальный параметр, он хранится где то пока этот удаленный документ не будет открыт, и если удаленный сервер перенаправил на другой урл - почему бы этому новому урлу тоже где то не храниться ?

 

[Фанат]

почему это не файл ?

потому что это тоже "документ". а не файл.

почему бы этому новому урлу тоже где то не храниться ?

обратись с этим вопросом к разработчикам пхп

-~{}~ 25.08.06 19:34:

я не улавливаю в чем проблема

проблема в том, что тебе давно сказали, как делать.
а ты всё хочешь добиться справедливости.

 

[itprog]

он хранится где то пока этот удаленный документ не будет открыт

хочешь чтобы он у тебя хранился? так засунь его в переменную или константу

sergep
Зачем ловить перенаправление? Его может вообще не быть - стоит "AddType application/x-httpd-php .zip"

Отдавать файл пользователю? Сохранять его на хостинге? Отправлять письмом? Для этого имя удаленного файла не важно.

не вижу проблемы... зачем ему это вообще надо?

 

[sergep]

Фанат, скажи по простому, ты точно уверен что кроме как с помощью запроса fsockopen нельзя никак иначе увидеть урл на который перенаправлен fopen ?

Просто ну не лежит у меня душа к тому что-бы вручную разбирать ответы сервера. При анализе html кода страниц разных серверов - убедился, что html код может сильно различаться, например может быть src="/ а может и src='/. И всё это надо разобрать.

 

[Фанат]

правильно, кстати, не лежит.
как друзья-пэхапэшнечги этот локейшен пишут - весь w3c в обморок упадёт в полном составе =)

 

[sergep]

itprog, мне не надо ничего хранить

пользователь может запросить любой удаленный документ, и сервер должен прочитать его с удаленного сервера. Естественно файл пользователю он вывести не может, поэтому урлы проверяются по расширениям, что это не файл. Но на многих серверах урлы на файлы скрыты, и подменяются в процессе открытия удаленным сервером. И мне нужно перехватить или увидеть что именно открыл fopen или fsockopen, проверить, и если это файл - не выводить его пользователю.

 

[itprog]

sergep
скажи вот, какая катастрофа будет если при открытии zip файла будет перенаправление на другой адрес?

Так вот в чем проблема, проверяй content-type через fsockopen или get_headers

 

[Фанат]

itprog
в браузер под тайпом текст/хтмл полезет бинарник =)

 

[sergep]

itprog

на моем сервере есть компонент, с помощью которого пользователь может вызвать любую страницу с любого другого сервера, пользователь вводит урл на моем сервере, мой сервер открывает этот урл, вычитывает эту страницу и выводит в своем окне. Если пользователь вводит ссылку на файл - в окне вывалится код файла. Поэтому урлы на файлы проверяются, и выдается сообшение. Но многие сервера скрывают прямые урлы на файлы, т.е. дают обычную ссылку, а потом уже при запросе этой ссылки подменяют ее на реальный урл файла, мой сервер автоматом перенаправляется на урл файла и начинает открывать, в окне код.

-~{}~ 25.08.06 20:00:

itprog, серверам и тому что они говорят - не верю

видно придется проверять Hyper Text Continuation: Location: и сравнивать

надо будет тогда внимательно посмотреть что и как сервера могут отвечать, боюсь разнообразие ответов поразит

 

[Crazy]

Автор оригинала: sergep
Поэтому урлы на файлы проверяются, и выдается сообшение

И каким же волшепным (c) способом, позволь осведомиться, проверяются урлы?

 

[Igor aka TiGR]

sergep
Простое решение тебе уже предлагалось:
get_headers()

 

[sergep]

Crazy, а в чем проблема ?
например вот так проверяются:

if (preg_match("/(\.jpg$)|(\.gif$)|(\.jpeg$)|(\.png$)/", $url)) {echo '<img src="'.$url.'">'; return;}

Igor aka TiGR
get_headers
(PHP 5)
у меня 4-ый

а вообще подумал я и решил что настоящий герой должен идти в обход и решил всё сделать наоборот, проверять, что скачиваю html, а не что-то другое. Но и тут оказались некоторые тонкости. Итого:
Открываем файл, скачиваем как минимум 1К, т.к. оказалось, что есть страницы у которых перед первой угловой скобкой могут быть пробелы и вводы, удаляем эту ерунду, проверяем - если первый символ не < и вызывается не txt - это файл, если нет - качаем до конца если есть еще чего качать. Как минимум 1К вначале нужно скачать, т.к. fgets качает строками, а вводов может быть много.

$fp = fopen ($url, "r");
if (! $fp) {echo 'Файл не доступен'; return;}
while (!feof($fp)) {$page .= fgets ($fp, 1024); if (strlen($page)>1000) break;}
$page = ltrim ($page);
if ($page{0}!="<" and !preg_match("/\.txt$/", $url)) {echo 'Файл'; fclose($fp); return;}
while (!feof($fp)) $page .= fgets ($fp, 1024);
fclose($fp);

-~{}~ 28.08.06 10:20:

теперь кстати отпала необходимость проверять что это какой нить zip или док, достаточно проверить, что это картинка, флеш или ссылка на фтп, так как их надо по другому вывести, а всё остальное объявляется файлом

 

[Crazy]

Автор оригинала: sergep
Crazy, а в чем проблема ?
например вот так проверяются:

if (preg_match("/(\.jpg$)|(\.gif$)|(\.jpeg$)|(\.png$)/", $url)) {echo '<img src="'.$url.'">'; return;}

Дело лишь в том, что это бессмысленный код. Простейший тест на бессмысленность этого подхода к проверке:

http://rapidshare.de/files/25463566/Sybex_.Cabling.The.Complete.Guide.to.Network.Wiring._2004__.3Ed.DDU.part1.rar

Тот факт, что URL кончается на rar, jpg или gif в действительности ничего не говорит о типе контента, который будет отдан по этому URL.