@Deerenaros по OSI, на седьмом. По tcp/ip, на 4. )
По поводу сложности все учесть, согласен. Именно поэтому написал человеку дополнение, которое тоже может пригодиться в жизни. )
@Deerenaros@vvpoloskin я считаю, что в данном вопросе знание http протокола является достаточно существенным. Человек спрашивал о браузере, а это именно то, что делает браузер. DNS, модель OSI, сокеты, драйверы и клавиатуры - это другой уровень абстракции, о котором браузер и знать не хочет. Соответственно, это будет ответом не на этот вопрос.
Забыл рассказать про тонкости реализации HTTP протокола. Это тут гораздо важнее для понимания процессов, чем рассказ про нажатие на кнопку на клавиатуре.
В общем, составляя заголовки запроса, браузер для начала формирует заголовки, в которые включает некоторую информацию, которая ему известна (и которой нельзя доверять на сервере). Там он рассказывает, что он за браузер, говорит, какой контент он поймет в ответе, передает имеющиеся у него куки, откуда пришел пользователь (если кликал по ссылке) и кое какую другую информацию, которая может быть полезна серверу. Далее, если это, к примеру, пост запрос, он приложит тело запроса с данными формы. Как то так.
Про рукопожатия, происходящие между клиентом и сервером подробно не расскажу, не в курсе. В общем, происходит попытка установить соединение в рамках протокола. В случае успеха, если сервер ответил, браузер получает ответ от него.
В зависимости от результата обработки запроса сервер может ответить нам несколько разные вещи.
В случае успеха, он отдает нам 200 (или какой то из 2хх) статус, тоже расскажет браузеру, как его зовут, может прислать новые куки, рассказать о том, что браузеру ждать в контенте, стоит ли кешировать то, что он прислал, и кое какую другую инфу, по ситуации. После заголовков - содержимое (если есть).
Если сервер отвечает 3хх кодом - это соответствует редиректу. Тогда он добавляет заголовок, куда. В этом случае, браузер берет адрес (если он не дурак), который ему прислали, и повторяет все с самого начала по новому урлу.
Если код от сервера будет 4хх или 5хх - это будет означать ошибку клиента (не правильный урл, неподдерживаемый протокол, нет авторизации) и сервера (совсем плохо), соответственно. И отрисует стандартную страницу, если тело ответа пустое (или меньше определенной длинны, зависит от браузера). Если в теле есть контент, то отобразит его.
Далее соединение можно разрывать, обменяться прощаниями по протоколу и закончить работу на application level. )
О таких подходах я в курсе, но мне интересно, что бы мой сайт индексировался получше, работал в случае какой то незамеченной js ошибки, и т.д. Я знаю, как реализовать тупо шаблонизацию на фронте.
И даже в приведенном мной примере уже никакого дублирования на клиенте и сервере нет. Разве что, считать дублированием отдачу библиотеке шаблона и данных. )
Интересное решение. ) У меня использовался Log4jConfigListener. Но файл log4j.properties лежал в ресурсах и обращался я к нему через classpath. Перемещение в WEB-INF избавило от проблем с разными класслоадерами. Спасибо! )
Ну да... Файл свойств и класс грузятся разными загрузчиками классов. Читал я это. Только мне это дает слишком мало информации, так как ошибка происходит в классе спринга, и я не знаю, откуда там берется другой загрузчик. Тем более, что из логов я даже не вижу, в каком месте появляется этот загрузчик, который загружает этот org.springframework.web.context.support.XmlWebApplicationContext...
В общем, я бы хотел услышать совет от человека, который решал эту проблему, а не давал ссылки, которые я уже видел.
Распознать не сможет. Но я говорю о ситуации, когда слова уже есть. Есть их последовательность. По сути то нужно всего лишь распознать, где кончается одно слово и начинается следующее.
Точно. Я пробовал анотацию, с ключевым словом не сохраняет. Хотя, мне все равно этот вариант не подошел, так как мне необходимо сохранять это поле через hibernate. Видимо, придется что то свое писать.
