Slashdot Mirror
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?
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
Two wrongs don't make a right, three lefts do!
yep, minimizing works. we ask all our aol customers to do this.
-- Sig (120 chars) --
Your friendly neighborhood mIRC scripter.
* Q
P.S. If you don't get this note, let me know and I'll write you another.
you might want to take a look at http://aolserver.com there's a mess of documentation there about their web server.
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...
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.
Inktomi 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)
For more information, click here.
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
~ppppppppö
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.
Also, don't pass very long query strings around--they'll chop 'em.
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.
For more information, click here.
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 ...