Home/ Questions/Q 6003423
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T01:07:10+00:00

When communicating with our REST webservice, an http response with status code of 304

  • 0

When communicating with our REST webservice, an http response with status code of 304 is returned to indicate that the resource requested hasn’t changed. However our WP7 application, using the HttpWebRequest class, the phone is taking exactly 2 minutes before this type of response is successfully read.

    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);

I can see that the webservice is responding immediately with 304 and no body data, the request itself is not timing-out and our application is able to successfully handle other response codes [404, 201 etc]. Could it be a Silverlight browser “caching” issue?

Can anyone confirm that they’ve seen this before, or have any thoughts on the issue?

Cheers,
Alasdair.

== Additional Information ==

As a result of WP7 restricting certain request headers, we use a custom [If-Modified-Since] header for all our resource requests. This custom header [X-If-Modified-Since] is recognised by the firewall in front of the webservice and modified back to the standard header. I’m unsure if this is related to the issue described above.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Answered my own question in case anyone is interested or facing a similar problem.

    We eventually created a work around by configuring our webservice to respond with an OK (200) http status code, and writing the actual response code in a custom header X-Http-Status. On the client side when we parse the response, if this custom header exist then we take this to being the actual status code and continue with the business logic from there.

    This allows us to potentially deal with any additional status codes that the Windows Phone handles differently.

    The cause of the issue is still unknown, although we strongly suspect that since this is a NOT MODIFIED (304) code, some caching is happening at some low level layer in Silverlight before the response is made available to us.

    • 0