Так у меня эта ошибка появлятся и без этой опции конфигурации. Пакет libssl-dev в системе стоит. Другого пакета я не нашёл, на официальном сайте тоже нет — там исходники без разделения по архитектурам.
Как раз свой ./configure --help я и смотрю, но там не пишется включено ли то или иное расширение по умолчанию, вообще не написано какие значения по умолчанию. Просто список опций и их описание.
и вообще, где можно посмотреть какие расширения в PHP 5 включаются по умолчанию, соответственно опцию не обязательно указывать? Сколько гуглю, не могу найти инфу.
благодарю :) На самом деле я задавал вопрос с более глобальной целью: в опциях ./configure PHP есть много таких моментов, где нужно указывать "%extension% install dir" — мне непонятно было (и есть) что подразумевается в таких случаях под "%extension% install dir"? Папка исходников компонента? Папка куда был установлен компонент? Папка куда будет установлен компонент?
Только надо понимать, что он вовсе не обязательно моментально при появлении упоминания сообщит вам. Только когда поисковый паук пройдётся по очередному сайту и наткнётся на заданную вами фразу. А по сайту он может проходиться как раз в час, так и раз в месяц. Ну и конечно он не сообщит об упоминания, расположенных в закрытых от индексации ресурсах.
За рубежом стало модным проводить совещания/презентация/вебинары используя последнюю версию Skype (там можно теперь одновременно нескольким людям соединяться по видеоконференции). Ну и соответственно записывать на компьютер любым привычным средством (любой программой для видеозахвата).
Качество и устойчивость связи при этом, как правило, лучше онлайн-сервисов. Хотя, конечно, зависит от количества участников видеоконференции.
Всё равно непонятно почему они тогда избирательно этот подход применяют, а не для всех ресурсов. Интересно. Оттого и родилось подозрение, что возможно отдельные платформы типо мобильных браузеров некорректно воспринимают такую адресацию.
Окей, значит логично предположить, что для таких адресов поведение браузеров никак не отличается от адресов «привычных» (не вызывает дополнительных запросов к серверу и т.д.) Спасибо.
taliban, эммм… При критических сбоях ОС и жёсткого диска (когда бились секторы жёсткого) — видел. А так, чтобы при этом всё нормально работало — нет. А к чему вопрос?
Основана банальными проверками, я с давних пор (после того, как увидел у Яндекса) тоже применяю эту тактику. Можете для проверки создать в блокноте у себя на компе простую HTML страничку и вставить на неё внешнее изображение:
Просто опять же интересно почему они применяют такой подход «избирательно»? Некоторые ресурсы (картинки, скрипты) адресуют в такой форме, а некоторые в привычной всем, полной форме.
Ну видимо что просто работает — видимо действительно везде. А вот по части того КАК оно работает — тут они могли и пожертвовать некоторыми моментами. Просто я не знаю как этот механизм работает.
Представим что мы находимся на странице открытой по протоколу "https". На странице есть картинка с HTML-кодом <img src="//site.ru/pic.jpg"/>. Вот браузер её однозначно сразу запросит тоже по HTTPS или сначала проверит доступность по HTTP? Если второе — это дополнительный запрос, дополнительные возможные баги при неучитывании этого фактора. Яндекс мог такой «мелочью» пренебречь, а вот для других может это важно.
Да я его использую, давным-давно. Только для понимания ситуации поправлю вас: strip проводит не сжатие, а минимизацию файла. Это разные вещи. Он просто удаляет лишние пробелы, переводы строк и т.д.
Условно говоря, для частых запросов заранее компилируется и кэшируется в отдельную папку результат запроса (по сути готовый HTML-код ответа). Ведь теоретически можно сделать так, чтобы все файлы этой папки кэша заранее сжимались в статический, сжатый вариант.
Вопрос стоит в том, чтобы не нарушить логику системы отвечающей за кэш, ведь при сжатии изменятся и время модификации файла и его размер.
