Если в ответе на HEAD запрос, в Content-Type: нет указания charset= значит мы запросили заголовок файла, а не страницы.
Запрос со ссылкой на страницу:
авторHEAD /index.php?RSongID=2312&Link=2312 HTTP/1.1
Host: www.smallchurchmusic.com
Connection: close
User-Agent: compatible; MSIE 7.0; Windows NT 6.0


HTTP/1.1 200 OK
Date: Mon, 04 Jan 2016 16:42:34 GMT
Server: Apache
X-Powered-By: PHP/5.3.29
Connection: close
Content-Type: text/html; charset=UTF-8Есть charset.

Запрос со ссылкой на файл:
авторHEAD /Snippet/S-ABabeLies-Corner-PipeLC-48-CAM.mp3 HTTP/1.1
Host: www.smallchurchmusic.com
Connection: close
User-Agent: compatible; MSIE 7.0; Windows NT 6.0


HTTP/1.1 200 OK
Date: Mon, 04 Jan 2016 16:36:53 GMT
Server: Apache
Last-Modified: Thu, 22 Jul 2010 05:34:13 GMT
Accept-Ranges: bytes
Content-Length: 181139
Connection: close
Content-Type: audio/mpegНет charset'а.
Может кто-то знает причину, почему это плохо. Это нормальный способ проверять ссылку?

Я не разбираюсь в вэб-серверах, страница тоже файл конечно, но могу показать пример, когда html-файл в списке прочих файлов на странице.

И при HEAD запросе со ссылкой на такой html-файл в ответе нет шарсета, т.е. сервер отвечает, что это файл, он не выдаёт этот html как страницу.

Shocker.ProСтранная постановка вопроса. А что, страница - это не файл что ли?
Content-Type: text/html
Content-Type: audio/mpeg
Вот на это и смотри.Зачем? Я планирую качать и txt, и html, и mp3 файлы, не важно какое содержимое, важно что сервер отвечает на HEAD запрос.

Shocker.ProА.Smithстраница тоже файл конечнотогда хотелось бы услышать задачу. Пока что она звучит: "как мне отличить файл от файла"Какую задачу? Кто здесь будет выполнять задачу за меня? Не нужно придумывать. Начиная с названия темы был прямой вопрос.

Shocker.Procharset - это кодировка. И она может быть не указана даже для html-файла
Тебе нужно определиться, чем ДЛЯ ТЕБЯ отличается "файл" от "страницы".Да, при чем здесь Я вообще. Может кто-то знает, по какому случаю вэб-сервер не показывает charset для html-файла.
В тоже время тотже сервер показывает charset для html-страницы, на которой кстати ссылка на тот первый html-файл.

Думаю, что страница это не обязательно файл на сервере и мне также очевидно, что не каждый html-файл на вэб-сервере выдаётся как страница на HEAD запрос.
Я тоже подумал, что charset'а в ответе нет потому, что в html-файле нет, но вот он, в файле указан <meta charset="utf-8">, а сервер отвечает, без шарсета вот так:
авторHTTP/1.1 200 OK
Server: nginx/1.0.15
Date: Mon, 04 Jan 2016 17:50:13 GMT
Content-Type: text/html
Content-Length: 82042
Last-Modified: Fri, 20 Nov 2015 10:07:29 GMT
Connection: close
Accept-Ranges: bytesДа, вопрос я задал, но опять, не потому, что я что-то считаю, мне так сервер отвечает. Вот я и спросил, можно таким способом пользоваться или это не показатель?

Shocker.ProА.Smithhtml-файл на вэб-сервере выдаётся как страницау тебя каша в голове. Непонятно как ответить на твой вопрос, потому что ты в своих вопросах используешь бредовые утверждения.Мне точно нечего ответить человеку не отличающему вопрос от утверждения.

Я ничего не утверждал, моя цель не в этом. Я просто процитировал логи обмена, на которые ориентирую и мой вопрос был, можно ли на это полагаться.

Ну, вот я вычитал, что "мультиязыковые" сервера как вики могут не выдать charset'а, а в meta-тэге каждой конкретной странички указывают её charset.

Возможно протокол не обязывает сервер категорично указывать charset в заголовке ответа, но ведь поголовно все сервера его выдают при GET запросе страниц.

В ответе от википедии действительно в заголовке нет charset'а хотя запрос касался странички.
авторHTTP/1.1 301 TLS Redirect
Server: Varnish
Location: https://ru.wikipedia.org/wiki/User_Agent
Content-Length: 0
Accept-Ranges: bytes
Date: Mon, 04 Jan 2016 19:56:49 GMT
X-Varnish: 1214115036
Age: 0
Via: 1.1 varnish
Connection: close
X-Cache: cp3031 frontend (0)
Set-Cookie: WMF-Last-Access=04-Jan-2016;Path=/;HttpOnly;Expires=Fri, 05 Feb 2016 12:00:00 GMT
X-Client-IP: 91.215.221.250
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
Set-Cookie: GeoIP=RU:12:Grozny:43.31:45.70:v4; Path=/; Domain=.wikipedia.org

Хочу определить, имеет ли смысл скачать и сохранить как файл то, что по ссылке. Но похоже ориентироваться можно только по хвосту ссылки.
Если там что-то типа .xxx или .xxxx, то можно качать это в файл, а иначе наверняка скачаю какую нибудь страничку сайта.

Я долго втыкал в названные тобой вещи когда самостоятельно пытался написать сетевую часть.
Пользуясь асинхронными API посылал GET запросы, контролировал и парсил ответ, искал ссылки.
Но поиск по этому форуму навел меня на темы Дмитрия77, а он вполне обосновал пригодность IE.
Теперь, прежде чем показать пользователю список ссылок я отфильтровываю ссылки на страницы.
Именно так, как я уже указал не смотря на то, что в список попадут и статичные странички сайта.
Главное, что туда не попадёт потенциально-многочисленный мусор ссылок на php страницы и т.п.
Из этой темы я вынес мысль, что нельзя ориентироваться только на отсутствие charset в заголовке.
Возможно я совмещу эту проверку с проверкой расширения, хотя какое там расширение у ссылки.
Просто нет смысла содержать приличный потенциально настраиваемый список типов Content-Type.

Ну разумеется это значительно повысит гибкость настройки, но это и раздувает настройки. Я стараюсь не забывать о целесообразности. Не всё же в угоду исскуству))

Однако. Т.е. ты советуешь проверять тип контента и отфильтровывать text/html, а если нужны htm(html) выключать фильтр? Кажется это то, что нужно.

И сейчас тот пост выглядит лишь как намёк. А тогда смысл понимался совсем по-другому. Ято считал, что сервер как-то направляет браузер.
Это возможно. На другом форуме мне показали, что действительно сервер принуждает браузер скачать, а не отобразить предлагаемый файл.