Время ожидания HttpWebRequest для ответа с кодом состояния 304 - PullRequest
Новая
       27

Время ожидания HttpWebRequest для ответа с кодом состояния 304

0 голосов
/ 18 апреля 2011

При связи с нашим веб-сервисом REST возвращается http-ответ с кодом состояния 304, указывающий, что запрошенный ресурс не изменился. Однако в нашем приложении WP7, использующем класс HttpWebRequest , телефону требуется ровно 2 минуты, прежде чем этот тип ответа будет успешно прочитан. 

    HttpWebRequest request = HttpWebRequest.Create("path/to/unchanged/resource") as HttpWebRequest;
    request.Method = "GET";
    request.BeginGetResponse(
        new AsyncCallback(
            (aysncResult) => {
                // response is read correctly here... 120 seconds later
            }), null);

Я вижу, что веб-служба немедленно отвечает 304 и данными тела нет, сам запрос не имеет тайм-аута, и наше приложение может успешно обрабатывать другие коды ответов [404, 201 и т. Д.]. Может ли проблема с кэшированием в браузере Silverlight?

Может кто-нибудь подтвердить, что они видели это раньше, или есть какие-либо мысли по этому вопросу?

Ура, Алистер.

== Дополнительная информация ==

В результате WP7, ограничивающего определенные заголовки запроса , мы используем настраиваемый заголовок [If-Modified-Since] для всех запросов ресурсов. Этот пользовательский заголовок [X-If-Modified-Since] распознается брандмауэром перед веб-службой и изменяется обратно на стандартный заголовок. Я не уверен, связано ли это с проблемой, описанной выше.

1 Ответ

0 голосов
/ 10 июня 2011

Ответил на мой собственный вопрос, если кто-то заинтересован или сталкивается с подобной проблемой.

Мы в конечном итоге создали обходной путь, настроив наш веб-сервис на ответ с кодом состояния OK (200) http и записав фактический код ответа в пользовательский заголовок X-Http-Status. На стороне клиента, когда мы анализируем ответ, если этот настраиваемый заголовок существует, мы принимаем его за фактический код состояния и продолжаем с него бизнес-логику.

Это позволяет нам потенциально иметь дело с любыми дополнительными кодами состояния, которые Windows Phone обрабатывает по-другому.

Причина проблемы до сих пор неизвестна, хотя мы сильно подозреваем, что, поскольку это НЕ МОДИФИЦИРОВАННЫЙ (304) код, некоторое кэширование происходит на каком-то низкоуровневом уровне в Silverlight, прежде чем ответ станет доступен нам.

...