An Operator Decides to be Polite…

Say what you will about the network operators with whom we have to play in the mobile space, but every now and again they do think of the developer community before implementing changes that may impact us all. Case in point, our friends over at AT&T devCentral recently sent out an announcement to the developer community about changes that will be coming as a result of some modifications to their gateway.

On my birthday over the weekend, I got a greeting from the devCentral folks at AT&T outlining the changes that are coming from their network and actually asking for feedback before they go into place. Imagine that, proactive notification! Before I get too excited about it, I will say this: it was great to get this message in an email, but unfortunately, I can’t find it posted on the devCentral website anywhere (please let me know if you can find it…). For those of you who are not on the mailing list for the AT&T Developer Program, or who sent this message straight to /dev/null here are the highlights:

User Agent token insertion

The new gateway that AT&T will be rolling out will no longer append the gateway version information to the tail end of the user-agent string sent. This means that instead of getting something that looks like:

You’ll no longer be getting the UP.Link/x.x.x part of that header. Ok, so this means that you’ll not have visibility into if the request is coming via a gateway or via a direct connection from a device (like if it’s accessing you via a wifi AP instead of via EDGE/GPRS. That’s something that you could probably live with, except when you combine it with this next change:

Absence or reformatting of “via” header

So, right now when you get a request from a device that’s routing through a gateway, you’re supposed to also get an HTTP-VIA header indicating just where this request is routing through. In the request from the user-agent referenced above, that header looks like:

It’s another indicator to you that your end user is coming through a proxy of some sort which may (or may not) muck with both the request and your response. It also gives you another clue to the fact that you’re not coming directly and may be on a slower line (slower than wifi that is…).

Now when you combine the two changes listed above, suddenly you’ve lost visibility into what network elements may be sitting between you and the end user. I’m not suggesting that AT&T is about to start monkeying with your requests, or inserting reformatting proxies, but if they were to, you’d have a hard time telling at this point.

Potential change in the order in which Accept headers are sent to Content Providers

If your content adaptation solution relies on the order in which supported media types appear in the accept header, this would cause you problems. That said, if you’re relying on the order to begin with you’re already skating on very thin ice and it’s time to move to something more robust. The only thing that you should be relying on in the header to give you an indication of media type preference would be the q values (if present). The order in the headers is meaningless.

Elimination of x-up-devcap headers

I honestly don’t know if anyone still uses these anyway. They’re known to be a tad on the unreliable side and are often just missing anyway. If you still rely on the data contained within, it’s way past time for you to move to using e.g. DeviceAtlas.

So, what should you do today?

1. Well, first of all, if you’re delivering content in the US, be sure that you’ve signed up for the AT&T Developer program. Not only will you get pertinent notifications like the one I refer to here, but they’ve got some pretty decent information about their devices and network out there for you.
   If you’ve got concerns about the proposed changes, please comment on this article, and let the folks at AT&T know. They’re asking for feedback before September 5 2008. If you’ve got real applications that this will impact, speak now! I can speak in the abstract here, but concrete examples are what is going to make the difference
2. As suggested above, (and in previous posts) leverage robust content adaptation solutions and device information tools such as DeviceAtlas or the WURFL.

I hope that this is helpful information, and I’m happy to pass along the full email from AT&T if you’d like it. I’m not posting it here since I don’t have the rights, but if and when I get a link to it from the folks in the dev program over there, I’ll update you all.

Enjoy!

Ron