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

При взаимодействии с нашим веб-сервисом 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] распознается брандмауэром перед веб-службой и возвращается к стандартному заголовку. Я не уверен, связано ли это с проблемой, описанной выше.


httpwebrequest http-status-code-304 httpwebresponse windows-phone-7
person ajmccall    schedule 18.04.2011    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

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

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

Причина проблемы до сих пор неизвестна, хотя мы сильно подозреваем, что, поскольку это НЕ ИЗМЕНЕННЫЙ (304) код, некоторое кеширование происходит на каком-то низкоуровневом уровне в Silverlight до того, как нам станет доступен ответ.

person ajmccall    schedule 10.06.2011