This seems to be a dead forum, but I`ll take my risks and post here, hoping to find a solution. Starting on October 11, 2005, I have been getting numerous complaints that my previously working site/wap-app suddenly started giving "page error" errors. After investigating, I realized that no changes had been made on my side. One user said the problem cleared inbetween up for about a day but then went back to giving the error. The problem has now progressed that the main page no longer displays. All of my wml code validates. There are no special exentions, phone specific code, browser specific code, etc. The suddeness of the complaints led me to be believe that something was changed in Sprint's wap gateway. Only Sprint users are facing this problem. I thought that the gateway placed a new limit on page size. A user reported that my test page from 10 upto 10,000 characters displayed just fine. I have looked at the Style Guide (woefully out of date) and searched in these forums to no avail. If someone can tell me what changed from Sprint's end, I can try to fix or find a workaround on my end. Thank you.
Hi, I`ve got exactly the same complaints from Sprint users. I checked pages that users reported to be can't accessed but there was nothing wrong, all other users can browse that pages normally but Sprint users can't. I believe it's issue with Sprint's wap gateway too. It happened suddenly, before I thought it may be related to users phone (Sanyo) but it was working before so this can't be their phones. A technical assistant at Sprint tried the same pages with a Samsung phone and he also reported the same errors. Sprint must look into this issue as soon as possible. I got users to send their complaints to Sprint, hopefully they'll fix it. Regards Ahmet Ozen
An update to the Sprint Nextel infrastructure has the gateways modifying the data in order to improve bandwith. Unfortunately, this can distort some types of data. You need to add the following to your HTTP header to prevent the gateways from modifying the data: "cache-control: no-transform".
Thank you, Thompson. I`ve gotten a few reports that the header worked. However, this header causes other network's gateways to produce "file format unknown" errors. Is there any way determine that a user is on the Sprint network, so I can only send the header for Sprint users? I was thinking along the lines of an IP address range(s) or info/headers that Sprint's gateway adds to outgoing requests. -- Neerav
Can you please give an idea about how to use no-transform code in WML pages? <meta http-equiv="Cache-Control" content="no-transform" forua="true"/> doesn`t work but these work: <meta http-equiv="Cache-Control" content="must-revalidate" forua="true"/> <meta http-equiv="Cache-Control" content="no-cache" forua="true"/> Recently Sprint users getting alot of errors on almost every wap page. Can't you just disable transforming the pages at least for WML pages?
I agree that Sprint should configure the gateway so that wml content passes through without compression. It is impossible for every single wapsite owner to make this Sprint-specific fix on their sites. But I`m not holding my breath.... In November 2005, after requesting (and receiving nearly 500) _ENV and _SERVER dumps from Sprint users, I was able create the following php code which has so far proved to be very effective: // For SprintPCS-Nextel, possibly others, to prevent compression by the gateway // by Neerav Modi <gmobile AT sayni DOT net> if ( ((isset($_ENV[`HTTP_VIA`])) and (strpos($_ENV[`HTTP_VIA'], ".sprintspectrum.com:") !== false)) or ((isset($_ENV['HTTP_X_UP_UPLINK'])) and (strpos($_ENV['HTTP_X_UP_UPLINK'], ".upl.sprintpcs.com ") !== false)) or ((isset($_SERVER['HTTP_VIA'])) and (strpos($_SERVER['HTTP_VIA'], ".sprintspectrum.com:") !== f alse)) or ((isset($_SERVER['HTTP_CLIENTID'])) and (strpos($_SERVER['HTTP_CLIENTID'], "sprintpcs.com") != = false)) ) { header("Cache-Control: no-transform", false); } Note: It is a header, and not a meta tag. The no-transform is meant for the gateway and should not or rather does not need to reach the phone. Hope this helps.
In the past 10-14 days several thousand Sprint users registered on my site (who have been using the site fine for a whole year) are now no longer able to login unless they google search the site/or download mini opera - both options taking them to the webversion instead of the wap version - meaning they are virtually unable to use the site on their cells! These members are all contacting Sprint and informing me that Sprint have said it is the fault of my site! - the members are also suddenly unable to access other wapsites they have previously visited so something has to have changed recently! I would be very grateful if someone would let me know if there is anything else that can be done as my site is fast losing thousands of users. I am more than willing to work with Sprint on this. If anyone has anymore advice (I have copied the above replies to my technical guy) then feel free to email me mich@dazzlewap.comor inbox BEDAZZLED at www.dazzlewap.com Thanks in advance Mich
Yes, there is a problem with Sprint phones processing certain WML constructs. I too have a subscription service with thousands of users, many of whom have Sprint. First reports of a problem came in about 2 weeks ago. The problem does not affect all users of Sprint, but it is indeed isolated only to Sprint. Some handsets work fine, others do not. The handset factor may be a red herring, it may simply be that the unaffected users are trasacting through other WAP gateway servers at Sprint that do not have the problem. I have narrowed the issue down to the sometime-inability of Sprint gateways to properly process WML POST requests from "<anchor><go>" constructs. The variables contained in the <postfield> cgi paramerters do not get properly resolved, in fact what you will get in your CGI parser is the variable names themselves, and not the underyling values. The quick-fix is to change your WML <go> tags to have method="get" instead of method="post". The downside to this quick fix is that you are limited to the cgi get buffer length for the sum total of the <go> URL plus the cgi parameters and their values. W3C RVC`s spec the "get" buffer length, but in reality they are highly implementation dependent. Depending on the CGI payload that your application works with, this may or may not be a factor. The other downside is that the user gets one whopper of a bookmark URL if they happen to inspect it, to say nothing of the security issues as the CGI parms and values are exposed in the URL. Rest assured that if you call Sprint customer care, you will find that their stance is that it is not their problem. But rest assured as well that it most certainly is. Sprint support folks, as with all cell carrier support personel, are not very well versed in the details of wireless data in any form. The are however very good at selling you way more calling minutes than you will ever need... :) Regards, -Dave
Thankyou for your reply and email... you`re right I did forget to state that its only people with certain models of Samsung and Sanyo that cannot get in via the normal method, whilst other Sprint users still manage to access us - although its almost like whatever is being done is being done in stages as the number started as just a few but is growing in stages. We have fixed all the possible "blame" areas and 2nite my colleague has even tried testing the basic wap-only site proving that our addition of a webversion is not to blame (Sprint operatives are still saying to members ringing them that there is a problem with MY site not THEIR carrier!) I am in the UK as are my servers and so far I cannot even get a reply from any email address at Sprint i've tried.... my members are all getting month after month of "free internet" etc and even new handsets being thrown at them....which are not much good when they cannot use them for the purpose they wish to use them for. After checking the logs 2nite when a Sprint user entered the wap version it showed that the gateway was streaming content.
