Как сервер и / или браузер по-разному обрабатывают файлы JSP и JSPF?
Изменить: Этот вопрос был задан в ответ на неправильные замечания, которые я сделал. Не обращайте внимания на.
Я знаю, что JSPF используются для определения фрагментов, которые могут быть включены в JSP.
Помимо этого соглашения, существуют ли различия в том, как сервер (например, Tomcat) или пользовательский агент (например, Firefox, бот Google и т. Д.) Могут обрабатывать файл?
На нашем веб-сайте есть несколько всплывающих окон / диалоговых окон, которые загружаются через AJAX. Содержимое для большинства из них хранится внутри JSPF и упоминается в URL (например, http://www.domain.com/folder/file.jspf). Недавно мы обнаружили, что если всплывающее окно находится внутри JSP, оно будет вести себя по-другому следующим образом:
1) Google будет индексировать его как отдельную страницу.
2) JQuery's $(document).ready(function() {alert('this code is executed')}); никогда не бежит.
2 ответа
Единственный способ создать URL для получения файла jspf - это поместить их в тот же каталог, что и обычные файлы JSP. (Это недопустимо, если вы помещаете их в /WEB-INF/). Поэтому, когда вы это сделаете, это будет зависеть от контейнера, который вы используете. Tomcat извлечет страницу в виде текстового документа. Однако интерфейсный веб-сервер может блокировать эти URL-адреса. Что обозначает расширение.jspf? Как это скомпилировать?
Надеюсь, поможет.
Прежде всего, браузер не обрабатывает файлы JSP и JSPF напрямую.
Вместо этого браузер запрашивает ресурс по URL-адресу, а сервер (в вашем случае Tomcat) отвечает документом в формате HTML.
Да, вы просили .jsp ресурс, но сервер скомпилировал страницу, и Tomcat выдал HTML-вывод в браузер.
В этот момент браузер обрабатывал обычную HTML-страницу.
Я вижу потенциальную проблему с прямым доступом к файлу JSPF через URL. Фрагменты должны быть включены специальной директивой JSP: include, Увидеть Use of Composite View Patterns в кодексе конвенций