HTTP-запрос возвращает 200 OK, но нет содержимого в ответе
при разработке конкретного веб-сайта у меня есть прерывистая проблема при загрузке сайта в Firefox (не удалось сравнить в IE или Chrome). Сайт загружает несколько файлов JavaScript, CSS стилей, картинок и т. д. Иногда один или несколько файлов не загружаются должным образом. Ответ указывает состояние 200 OK, но длина содержимого указывает 0. Это происходит в разных файлах в разное время. Когда файл javascript не загружается, сайт не загружается функция правильно, но все еще может отображать содержимое. Если это индекс.html-файл, который не загружается, Firefox отображает пустую страницу со следующим html:
<html>
<head></head>
<body><pre></pre></body>
</html>
(Я считаю, что это происходит из Firefox как "пустой" вид страницы по умолчанию)
похоже, что предыдущие успешные загрузки могут быть правильно извлечены из кэша браузера, а статус ответа 304 не изменен. После сбоя при следующем запросе ресурса мы видим ответ состояние 200 ОК, с последующими запросами снова отвечая с 304-х.
вот примеры заголовков запроса / ответа, Как сообщает Firebug:
Общий Успех Дела: (статус ответа: 304 не изменен, длина контента: 288)
Запрос Заголовков:
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en/q=0.5
Connection: keep-alive
Cookie: JSESSIONID=<shouldn't matter>
Host: ???.???.???.???:8442
If-Modified-Since: Tue, 29 Apr 2014 13:18:26 GMT
If-None-Match: W/"228-1398777506000"
Referrer: https://???.???.???.???:8442/mySite/
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131023 Firefox/17.0
Заголовки Ответа:
Cache-Control: no-cache
Date: Tue, 29 Apr 2014 13:36:35 GMT
Etag: W/"288-1398777506000"
Expires: Thu, 01 Jan 1970 00:00:00 GMT-00:00
Pragma: No-cache
Server: Apache-Coyote/1.1
Заголовки Ответов Из Кэш:
Accept-Ranges: bytes
Cache-Control: no-cache
Content-Length: 288
Content-Type: text/javascript
Date: Tue, 29 Apr 2014 13:36:35 GMT
Etag: W/"288-1398777506000"
Expires: Thu, 01 Jan 1970 00:00:00 GMT-00:00
Last-Modified: Tue, 29 Apr 2014 13:18:26 GMT
Pragma: No-cache
Server: Apache-Coyote/1.1
вкладка кэш в Firebug указывает на следующее:
Data Size: 288
Device: disk
Expires: Wed Dec 31 1969 18:00:00 GMT-06:00 (CST)
Fetch Count: 81
Last Fetched: Tue Apr 29 2014 08:28:35 GMT-05:00 (CDT)
Last Modified: Tue Apr 29 2014 08:28:35 GMT-05:00 (CDT)
Не Случай: (статус ответа: 200 OK, Content-length: 0)
Запрос Заголовков:
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en/q=0.5
Connection: keep-alive
Cookie: JSESSIONID=<same as above>
Host: ???.???.???.???:8442
If-Modified-Since: Tue, 29 Apr 2014 13:18:26 GMT
If-None-Match: W/"228-1398777506000"
Referrer: https://???.???.???.???:8442/mySite/
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131023 Firefox/17.0
Заголовки Ответа:
Content-Length: 0
Date: Tue, 29 Apr 2014 13:36:28 GMT
Server: Apache-Coyote/1.1
вкладка кэш в Firebug указывает на следующее:
Data Size:
Device: disk
Expires: Wed Dec 31 1969 18:00:00 GMT-06:00 (CST)
Fetch Count: 83
Last Fetched: Tue Apr 29 2014 08:28:42 GMT-05:00 (CDT)
Last Modified: Tue Apr 29 2014 08:28:42 GMT-05:00 (CDT)
далее Случай Успеха: (статус ответа: 200 OK, Content-length: 288)
Запрос Заголовков:
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en/q=0.5
Connection: keep-alive
Cookie: JSESSIONID=<same as above>
Host: ???.???.???.???:8442
Referrer: https://???.???.???.???:8442/mySite/
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131023 Firefox/17.0
Заголовки Ответа:
Accept-Ranges: bytes
Cache-Control: no-cache
Content-Length: 288
Content-Type: text/javascript
Date: Tue, 29 Apr 2014 13:37:03 GMT
Etag: W/"288-1398777506000"
Expires: Thu, 01 Jan 1970 00:00:00 GMT-00:00
Last-Modified: Tue, 29 Apr 2014 13:18:26 GMT
Pragma: No-cache
Server: Apache-Coyote/1.1
вкладка кэш в Firebug указывает на следующее:
Data Size: 288
Device: disk
Expires: Wed Dec 31 1969 18:00:00 GMT-06:00 (CST)
Fetch Count: 85
Last Fetched: Tue Apr 29 2014 08:28:54 GMT-05:00 (CDT)
Last Modified: Tue Apr 29 2014 08:28:53 GMT-05:00 (CDT)
мы размещаем сайт в JBoss-EAP v6.1, и я пробовал это в Firefox 10, 17 и 24 с теми же результатами. Я понимаю, что есть более новые версии (не говоря уже о различные браузеры), но они не обязательно являются вариантом для нас. Я надеюсь, что решение-это простое изменение конфигурации, но в моих попытках найти эту проблему я не видел никого, у кого была бы такая же проблема, поэтому это может быть не так просто. Я ценю любые предложения. Кроме того, Пожалуйста, дайте мне знать, если мне нужно предоставить дополнительную информацию (например, веб.XML-файле, на JBoss.conf, etc)
другие продукты в миксе:
- требуют.в JS-версии v2.1.2
- Java 1.6
- CAS 3.2.1
- атмосфера 2.1.3
обновление: я по существу исключил возможность проблемы с кэшем. Я реализовал процесс загрузки модуля перебора кэша, как предложено в RequireJS API страница, и я все еще вижу проблему. На этот раз, однако, вместо всех 304 кодов состояния, они все 200.
обновление 2: я скачал источник для JBossWeb 7.2.0.Final и работал через отладку этой проблемы. По-видимому, есть класс под названием org.апаш.койот.http11.Http11ConnectionHandler, который поддерживает пул экземпляров Http11Processor, каждый со своими собственными объектами запроса и ответа. Когда запрос завершен, Http11Processor "перерабатывается" и возвращается в пул.
похоже, что в логике рециркуляции может быть проблема с потоками, потому что ответ.recycle должен установить "committed" на false, но моя (условная) точка останова сразу после вызова ответа.recycle () останавливается с ответом.committed = = true. Это то, что вызывает неудачные ответы позже. Когда Http11Processor, содержащий уже зафиксированный объект ответа, ответ не может использоваться для возврата какой-либо информации. Он просто отвечает статусом: 200, Content-Length: 0.
это, кажется, происходит, когда я закрываю веб-сайт с атмосферным подключением, который использует сервер сопутствующих мероприятий. я неправильно использую Атмосферное соединение? Есть ли специальная логика очистки, которую я должен реализовать?
2 ответов
To чтобы эта модификация не повлияла на сервер JBoss, я добавил в jboss следующее.файл свойств:
org.apache.catalina.connector.RECYCLE_FACADES=true
другой вариант-использовать менеджер безопасности. (См. раздел Безопасность этой страница, и советы, предлагаемые в последних нескольких абзацах этой страница)
это, по-видимому, предотвращает переработку запросов и ответов, поэтому мы всегда получаем новый экземпляр ответа для каждого запроса.
У вас, вероятно, есть блок try catch, который проглатывает ошибку и не производит вывода. Возможно, он регистрирует ошибку где-то.