On Wed, Jul 13, 2011 at 1:41 PM, Indicator Veritatis <[email protected]> wrote: > I am glad you found a fix. But doesn't this raise a red flag? It > sounds like a band-aid, a kludge, a temporary fix rather than an > industrial strenght solution. After all: it means that that GET > request will not be cached by ANY agent along the chain. That sounds > rather draconian, unless you are 100% positive no one will ever do the > same GET request twice, expecting the same data.
Those GET's are calling a CGI (a dictionary server), so while it's possible that two people on the same network will send the same request (=search for the same word), the likelihood is fairly low. > > Of course, if the proper fix has to be implemented either at the > origin server or the proxy (and you have no control over these), you > may have to make the "temporary fix" permanent anyway. > I don't have control over the dictionary servers, but I can get in touch with their maintainers. I could probably get them to add no-cache headers, but that would affect a lot more people than the users of my app.. The problem seems to be (no hard proof yet, but I've seen this before) that some mobile network providers are aggressively caching HTTP to save on bandwidth, and that doesn't work too well with those particular servers. It might be due to the slightly creative use of HTTP parameters, or maybe those proxies are just misconfigured. I certainly have no control over them, so I think the best way to handle this is to set the headers at the client. If you have any other ideas, I am open to suggestions. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
