locked
IXMLHTTPRequest2 is returning cached responses

    Question

  • I am using IXMLHTTPRequest2 to send commands to my server.  I am finding, however, that if I send the same command 2 times in a row, that I receive a cached response rather than a new response from the server.  This cached response seems to persist until I kill my app and restart it.  How can I specify that I do not wish to ever receive a cached response?

    Thanks.

    Tuesday, February 26, 2013 5:24 PM

Answers

  • You can't. A gross hack is to append random/unique junk to your url (e.g. "?blah={timeinseconds}") for each request. Of course, this completely floods the cache and fills up users' disk space. I ended up writing a simple http client using sockets. What an absolute joke!

    Tuesday, February 26, 2013 5:34 PM

All replies

  • You can't. A gross hack is to append random/unique junk to your url (e.g. "?blah={timeinseconds}") for each request. Of course, this completely floods the cache and fills up users' disk space. I ended up writing a simple http client using sockets. What an absolute joke!

    Tuesday, February 26, 2013 5:34 PM
  • Thanks for the reply, I had already thought of the idea of adding a counter to the commands, but, as you say, this is less than ideal.  This 'feature' makes implementing a web service pretty hard.

    Can someone from Microsoft comment on when(if?) this will be fixed?

    Thanks.

    Tuesday, February 26, 2013 7:04 PM
  • Here is my post from October on the WinRT caching:

    http://social.msdn.microsoft.com/Forums/en-US/winappswithnativecode/thread/dadbea2e-85d4-4af0-9283-2f91e5b7cc2c

    And here's my post on the WinPhone8 forum about the same issue (which is more severe on WinPRT than WINRT):

    http://social.msdn.microsoft.com/Forums/en-US/wpdevelop/thread/4c6d99ba-5419-469a-9439-a1873a53c333

    There are a few comments by MSFT folks on those threads. Obviously, they know about the problem but there is no timeline for a fix.

    I abandoned my WinRT effort once I found that my regular old desktop programs worked fine on Intel W8 tablets. WinPhone8/WinPRT is worse for C++ devs (believe it or not, C++ can't access XAML on WinPRT!) but I was able to write a simple http client in WinSock that met my needs. Of course, WinSock isn't available in WinRT, so you'd have to use the system socket interface, which is completely different and more complex than WinSock. WinRT and WinPRT are written in C++, so why the C++ interface for ISVs is so FUBAR'd is beyond me. Makes no sense.

    Wednesday, February 27, 2013 5:03 AM
  • Thanks for the links, that is most enlightening.  I was not aware that I would not be able to access XAML from C++ on the Phone.  I have some phone apps that I WAS going to port over, but if I cannot reuse my WinRT code, I may bag it.  So far, I have been very unimpressed with sales of my WinRT Windows Store apps and I suspect that Phone sales will not be all that interesting either.  I am really beginning to regret going down this road.
    Wednesday, February 27, 2013 6:13 AM
  • Thanks for the links, that is most enlightening.  I was not aware that I would not be able to access XAML from C++ on the Phone.  I have some phone apps that I WAS going to port over, but if I cannot reuse my WinRT code, I may bag it.  So far, I have been very unimpressed with sales of my WinRT Windows Store apps and I suspect that Phone sales will not be all that interesting either.  I am really beginning to regret going down this road.

    The WinPhone8 C++/XAML issue was a shocker to me as well. Apparently it was mentioned at one of the talks in June 2012. I was able to move the C++/Direct3D core from my abandoned WinRT app over to WinPRT with almost no issues (the XAML-Direct3D linkage is different on WinPhone8 but the core is exactly the same). However, I had to create a shell for it in C# and then deal with all the interfacing issues between C++ and C#. A royal pain in the behind. The MSFT talks act like this is an easy thing to do ("just create a ref class in your C++ component to interface between them"), which is great if all you're doing is adding two number together. What about when you have dozens of knobs and complex settings, you know, a REAL program???

    Then there were the problems with IXMLHTTPRequest2, where WinPRT's version would never handle if-modified-since GET requests properly (WinRT's implementation appeared to work).

    WinRT and WinPRT are essentially 1.00 products and it shows. While that may be fine for a small company, it isn't for the flagship product of a company with 90K+ employees. Could they not spare a few interns last Summer to work on a C++ interface to XAML in WinPRT??? The lack of technical leadership at the top of MSFT is going to kill it.

    Wednesday, February 27, 2013 4:01 PM
  • My thoughts exactly.  During my working with WinRT my thoughts have always been, well this is about 80% done.  I can give you numerous examples where there are things that should have been done, but were not (this network stuff is only one such example).  The sad fact is the whole Windows 8 user experience is also only 80% done.  I was actually shocked when I purchased a Surface tablet only to find that it is a very odd mixture of a touch tablet interface and a normal Windows desktop.  I suppose having the desktop present is interesting, but the fact is there there are a number of things that you might want to do that seem to only be possible by switching to the desktop, and unless you plug in a mouse, you are going to have a hard time if you have fat fingers (as do I).

    The fact that they have 2 different operating systems for their tablet and their phones is also disturbing.  Neither Apple or Android does this.  Do they really expect us developers to write our apps twice?

    And don't even get me started on the Windows Store.  It does not even seem to be even 80% finished.

    How a company as big as Microsoft, with as many developers that they have could release such an unfinished product is a real mystery to me.  I have put a lot of effort into porting my apps from Android and iOS to Windows 8, and I suppose that I will finish up the effort, but I can tell you that if I was starting over with what I know now, I would not go down this road.

    Thanks again for your help.


    • Edited by John Gaby Thursday, February 28, 2013 4:19 PM
    Thursday, February 28, 2013 4:19 PM
  • A couple of final comments. I think the way MSFT is going is correct, using a mostly common core across all devices, it's the current implementation that's messed up (mainly from a developer's perspective). I expect/hope/pray that there will be more unification of the SDK platforms in the rumored "Windows Blue" sometime later this year. Of course, that doesn't help us right now and it also creates more fragmentation in the overall Windows 8 family.

    Note that I don't think that devs should necessarily be able to create one app that runs on all devices. That might work for the most simplistic apps but you will typically want to optimize your UI for the different screen sizes and usage scenarios, so you will have different code bases for that part. It's the underlying non-UI API set that needs to be completely common with "ears" in the API graph for device-specific functionality (WP8, XBox8). AND you need to be able to write a monolithic C++ app across all devices.

    All it takes is good technical leadership at the top. If Ballmer said "unify the platforms" and accepted nothing less (with an attitude, I get the feeling you don't hear, "this is bullsh*t", in the halls up in Redmond much anymore), it would happen.

    One last idea: MSFT should either get Dell to produce a no-compromises Alienware WinPhone8 or create their own "XBox" phone. MSFT needs to rip technical leadership away from AAPL and Samsung in the phone market, regardless of whether it is a moneymaker or not (how much money does MSFT blow on Bing every year?).

    • Edited by henador Friday, March 01, 2013 2:57 PM
    Friday, March 01, 2013 2:47 PM