В HTTP-протоколе не существует пустого адреса, минимально возможный - это слеш. Многие браузеры просто не отображают его в адресной строке, впрочем, как и сам протокол http://
$ telnet www.aquanet.ru 80 Trying 151.248.112.105... Connected to www.aquanet.ru. Escape character is '^]'. GET / HTTP/1.0 host: www.aquanet.ru
Вы не сможете вместо GET / HTTP/1.0 написать GET HTTP/1.0 - будет ругань
Из мне известных, tutanota.de - переписка хранится в зашифрованном виде, шифрование на стороне клиента. Open source, насколько я помню. Единственная большая проблема - если забудете пароль, то всё..
Ну вот, погуглил и сходу нарвался на какое-то исследование: http://www.rmj.ru/articles_4651.htm
А вообще, как-то из любопытства делал запрос, что-то вроде "коррекция зрения исковое заявление" - почитал выдачу и успокоился насчет идеи операции.
Я практикую в настоящее время, начиная с 13 мая с.г. Плюс еще понемногу добавляю разные методики, кроме Жданова, но от случая к случаю. Собственно, забрасывать не собираюсь и планирую до победного конца, сколько бы времени это ни заняло.
Было -3.75L, -4.25R. Сейчас -2.50L, 3.00R (занудно-регулярно документирую показания рефрактометров в кабинетах врачей, проверочные таблицы не интересуют).
Стаж близорукости 37 лет, из них, примерно последних 32 года, очки -3.75.
И да: больше тридцати лет, Карл, больше тридцати лет!
Ошибаетесь, уважаемый, этот вариант значительно лучше, я бы сказал - классический (для медленных запросов) 🍿
Да, разумеется. :)
Я также соглашусь, что крутить настройки апача (или что там у топикстартера) под такую задачу - плохой вариант. :)
Возвращаясь к самой задаче (это уже для автора топика), один из разумных методов для медленного post-запроса - это создание очереди в БД, записывать туда параметры запроса, возвращать клиенту "ваше задание поставлено в очередь на обработку", а каким-нибудь скриптом по cron-у разгребать, например раз в минуту, эту очередь.
А вот это, как раз, самое простое - поведение скрипта зависит от настроек веб-сервера. И да - там ни слова демагогии, я старался максимально доходчиво, на пальцах описать реальную ситуацию. Ну, проще уже никак нельзя 😕
Вы меня невнимательно прочитали, пхп ничего не знает о состоянии соединения до тех пор, пока об этом ему не сообщит сервер. Да и процесс прибьет сам сервер.
К вашему посту у меня образовалась тоже изрядная доля скепсиса.
Обрыв tcp-соединения может детектироваться операционной системой, путем посылки пробного пакета (в линуксе, например, пробный пакет посылается раз в два часа).
Понятно, что для веба это не вариант, поэтому, веб-сервер может самостоятельно пытаться определять обрыв соединения - но эта возможность определяется уже используемым http-сервером и его настройками - возможно проверка идет раз в секунду, возможно - раз в пять секунд, возможно - еще дольше. В общем, при обрыве соединения на стороне клиента, запущенный процесс будет еще некоторое время выполняться, и никакие пхп-шные функции здесь ничего не изменят.
голословное утверждение
покажите все заголовки ответа сервера на эту картинку, а так - гадать можно долго.
И еще - в урле картинки не следует ставить get-параметры (я не телепат, но всяко бывает)
