Are There Problems with AOL's Web Access?

Glowbead asks: "I run a web design company, and recently I've started stuggling with AOL. A client wants to use AOL as her service provider, which is fine, except that I can't get a submission form with 'type=mulipart/form-data' to go through. The form need to be multipart because they need to be able to upload images. I also can't get any info whatsoever out of AOL as to what the problem might be, other than this useless page. Does anyone know a way around this? Are there other standard problems you guys see when a client is using AOL to access your site? Can/How do you get around them?" This is not the first time I've heard of problems using AOL. What other gotchas have you all found when trying to use or access AOL's web-based services?

browser - not aol

[cheeserd00d]

the biggest problem i would have to see with AOL web access is the browser it uses - older versions of aol used a proprietary browser while newer version use Internet Explorer - lots of times the IE browser isn't updated, aol tends to be slow in updates, so certain bugs or unimplemented features won't work at all

just my two cents

Re:Well...

[hex1848]

yep, minimizing works. we ask all our aol customers to do this.

Re:bad page design

[Quietust]

In short, AOL's webmaster info page doesn't seem standard's compliant.

You've got that right, and here [w3.org]'s the proof.

-- Sig (120 chars) --
Your friendly neighborhood mIRC scripter.

some aol server specs

[heckler spray]

you might want to take a look at http://aolserver.com there's a mess of documentation there about their web server.

Well...

[True Dork]

I realize this can be difficult to get someone who uses AOL to do, but it might solve the problem. Get the client to connect with AOL as usual, and then minimize the AOL client. Fire up a normal browser and you should have a straight connection bypassing the cache proxies. I assume this still works with the newer AOL clients. I simply have not had to do this in a while. Perhaps you could send the client a diskette with a shortcut file and a DOS batch file to copy it into the start menu to make it easier to launch the browser.

I guess if it becomes a really large problem you could check the version of the incoming request and look for aol's string, redirecting them to a page explaining what they need to do to access what they are looking for.

Come to think of it, I have not tested any of my client pages for AOL viewers. I never really thought about it. Grrr, I guess it's time to grab an AOL trial coaster and fire up the the good old vmware...

caching proxies

[sohp]

AOL's web service is built on hordes of proxies caching pages for the clients inside their network. Their implementation is broken in that it doesn't properly obey the HTTP cache-control headers, meaning that if you have page that you want to expire or never be cached, you're fucked. There's no way to make AOL's proxies obey your desires. Our customer support group was trained to tell AOL users how to force a clean reload. Ugh.

Pay them off

[generic-man]

Inktomi [inktomi.com] now manages AOL's cache servers. From what I've heard from contacts at Inktomi, you'll soon be able to bribe Inktomi into making sure your page loads nice and fast for AOL users, especially faster than your competitors' sites. (wink wink, nudge nudge)

browser, proxy?

[titus-g]

Could it be the browser?

I'm not sure how it could be AOL as surely they are just providing the transport?, unless they have transparent proxy somewhere (quite likely).

If they do, and it does block multipart forms then there probably isn't much you can do, could check the browsers proxy settings in case it is not a transparent one, but one installed by default.

AOL do compress images when you browse, probably not relevant, but there is more info at http://home.earthlink.net/~jillb hart/AOLimage.html [earthlink.net]

Be worried about load balancing

[latin from manhattan]

If you use frames at your site, requests for the different frames will come from different IPs. Very difficult to load-balance effectively if you keep state on your servers.

Another load balancing issues comes from loading a helper app that loads a URL (like RealPlayer). The helper app may not use the AOL proxy servers, so it'll appear as a different IP address than the web client, and it probably won't support cookies.

Cisco has details on dealing with the "AOL problem" on its web site [cisco.com].

Also, don't pass very long query strings around--they'll chop 'em.

Re:bad page design

[generic-man]

It most certainly is standards-compliant. It fits every one of AOL's web standards to a T. It's bulky, has lots of crappy scripting to provide the disguise of functionality, and "real" web users scoff at it.

bad page design

[Louis_Wu]

My tale of trying to view AOL's webmaster page, as linked in the article.

• I tried to view the AOL "help" page from Opera 4.02, and the navigation frame on the left didn't show up. Funny, I can view the source.
• So I tried IE 5.5, figuring that AOL would support at least that browser (after all, they ship it as part of the package), and the frame's Javascript magically worked.
• Then I tried Navigator 4.74, and the Javascript worked again. Magic.
• I was then truly intrigued, so I put the page in Amaya (W3C's standard's demonstrating browser/authoring tool [w3.org]), and the page didn't load at all. None of the frames showed up, but I could look at the source if I wanted to.
• And I couldn't get Mozilla 17 to load the navigation frame at all, then the reload put the main frame in the navigation frame. (BTW, a connection was refused when attempting to contact webmaster.info.aol.com.) Persistent reloading got the main frame back into the right spot, but I still can't see the Javascript navigation frame on the left, though I can see the source.
• K-Meleon [slashdot.org] also gives me the connection error, but I can't get anything to show up on the screen.

In short, AOL's webmaster info page doesn't seem standard's compliant. Oh, and this is all from Win98, on a T1.

After this, I don't want to read about how to make my pages work with their software. If I can't even see their webpage with my browser, how can I trust them when they tell me what will work with theirs? Their suggestions would probably break Opera or Mozilla.

. . .

Oh, wait, their page has already broken Opera and Mozilla. Should I use "probably break", or should I use "will break (assuming hell doesn't freeze over)"?

Louis Wu

"Where do you want to go ...