25 thoughts on “Questions for web developers who code sites to work for AOL users visiting from AOL proxies…

  1. First, if any of them get internet through AOL as their ISP, the browser is forced into using the proxy settings no matter what options the browser thinks are set since AOL is the pipeline for all the data it will receive. Is there anyway around that?
    I can’t answer that question for you (but maybe someone else can?); in the meantime, let’s see what AOL has to say about cookies:
    Q. Does AOL cache cookies?
    A. A cookie is just another HTTP header line. It plays no role in the decision to cache a document. If the document does not contain the appropriate Expires header, the document and the cookie header may be cached. In most cases, it is an error for a web site to use cookie header lines without also using an Expires header. The future HTTP 1.1 protocol adds additional header control lines that may make cookie cache management easier to implement.
    So AOL blames the webmaster, not itself, if cookies are cached. Caching servers are the only servers capable of caching cookies (correct me if I’m wrong) yet AOL still deflects the blame, refusing to even acknowledge, for instance, that the technology, not the webmaster, is at fault. I emboldened the word “future” because 1.1 has been the HTTP standard for some time, a fact AOL acknowledges in their next Q/A.
    Assuming Jeff is successful at logging in…and the session retains the ID it started with including session variables, and cookies are enabled on both my server and…Jeff’s browser, where are the cookies stored? Jeff’s PC, or globally on the AOL Proxy Server?
    See Q/A above: Yes, AOL may cache the cookie, but if they do, they say that’s your fault.
    Now, Jeff either leaves or stays… Mary jumps online (also using AOL) and goes to her pages..Is she going to be logged in as Jeff… If Jeff is still on and has a session started, does Mary automatically become part of his session? Would this then cause Jeff to become Mary as soon as she logs in?
    Let’s see what AOL says about pretty much the same thing:
    Q. I am still getting old pages and I am certain that the site has been updated, how do I clear my BROWSER CACHE?
    A. Even though AOL’s Proxy cache is updated every 24 hours, a member can clear their Browser Cache and force the reload of a page. This is done by either..blah blah blah…
    So while AOL isn’t coming out and saying so in words, they’re tacitly acknowledging a problem by giving instructions on how and why to do a hard refresh.
    Comment character limit is at 4300 characters, so to be continued…

    Like

  2. continued…
    Sally logs in later…maybe. Will she also be logged in back and forth as herself, Jeff, and Mary? Does Bob inherit the same issue when he logs in even if Jeff has logged out? If Bob logs in and no one else is in at the same time to “interfere” with the session and cookie settings, will Jeff then see Bob’s info the next day when he logs in because Bob was the last value the session or cookie had?
    As per above Q/As, it’s possible. It’s supposed to be, according to AOL, your job to code headers in such a way that they expire after each session, and to ensure sessions expire when a visitor leaves (or logs out of) your website.
    Since AOL is supposed to kill the session after they log out.. (of AOL, not my site),
    AOL releases themselves from responsibility for this…they say it’s your job to kill the session when the user leaves, not theirs.
    …the session is likely destroyed. However, the cookie is still “in the jar” and fresh so that each user can be remembered when they return. Does AOL flush cookies automatically like the cache?
    If cookies are cached by AOL with the session, they’re flushed with the cache…every 24 hours. So if your question is, “Does an AOL user logging out of AOL kill the cookie AOL cached?”, the answer is No, not until the cache is flushed, which could be *up to* 24 hours after the first AOL user, Mary, showed up on your site.
    And if cookies are stored on the Proxy Server, how does AOL know which user has which cookie? If it is on the proxy server(s), does this mean that my site can only store 30 cookies for all X users at one time?
    I’m not sure what the “limit” is, but if your site doesn’t automatically create and end unique sessions for each AOL user, the cookie already on-board for the “first” AOL user, Mary, is going to be passed on to the next user, Jeff, with the same IP. See the next Q/A for why:
    Q. Can I use the IP address of the request to track a member’s access to my site?
    A. No. Because AOL uses proxy servers to service the requests made by members, webmasters see the IP address of the gr server, not the DAHA of the member in their web site log files.
    The problem with trying to use the IP address to track access is that there may easily be multiple members assigned to a proxy server. All of the member requests would appear to be coming from one member if you assumed a relationship between member and IP address. In addition, members may be reassigned to a different proxy server during a session.

    So in other words, let’s say Mary, an AOL user, shows up at your website with an IP of 255.32.3.10. That’s not the IP she’s actually using, it’s the IP she logged into AOL with before they switched her IP to a DAHA. Once AOL switches her IP over to the DAHA, you can’t see her real IP, which may keep changing while she’s on your site, anyway.
    As to your PHP questions, they’re way over my head. I do a tiny bit of s2/Perl coding so I have the barest understanding of that syntax, but that’s about it. Anyone else?

    Like

  3. Re: continued…
    Thank you for posting this. πŸ™‚ Hopefully it helps others and we find some solutions.
    …I understand from you article that AOL switches IP’s and that I cannot see the user’s actual IP. I guess it is a nice privacy feature and makes some since. However, my concern with this is what happens to the session (and session ID) when the IP switches. Does this trigger a new session (and new session ID and other session variables) or is the server able to understand this is the same “request”? I don’t know how it can tell that this is not a different user versus the same user.
    I liked your part about AOL blaming us for the cookie. According to this page (which is good info for web developers to know): http://webmaster.info.aol.com/aboutcookies.html
    “Chocolate Chip or Pecan?
    There are two different types of cookies distinguished by the expiration date: session and persistent cookies. Session cookies expire immediately after the user’s “session” ends. This usually means that the cookie sticks around until the web browser is closed and then is purged. AOL, however, keeps session cookies until the client is closed in its entirety. In other words, despite closing all the internal web browser windows within your AOL client, all session cookies received in the current session will remain resident. Persistent cookies, on the other hand, remain on the user’s system until the expiration date defined within the cookie. A cookie expires after one session by default.”
    Notice how they say that despite the normal behavior of browsers, AOL keeps it. So we cannot control the cookie. If it was at least saved to that user’s machine, no problem. But stored on a public server with user info…YIKES!!!

    Like

  4. Re: continued…
    Notice I misspelled “Sense” above because it really doesn’t make sense… πŸ™‚
    If the session ID is indeed stored in the “session” for the entire AOL log-in time, I would HOPE they at least keep the session active despite IP changes.
    The session “limits” are enforced (or not) by the browsers. Last I saw, the rule was each site/domain can store up to 30 cookies with a 4KB limit per cookie. Most browsers are supposed to hold no more than 300 cookies. If they are cached in the same location for all users and these “limits” are enforced, that would imply that out of all AOL users, only 30 users/cookies could be made at a time.
    Since we store 3 cookies plus the session ID cookie made by the server per user, which is fine when they have their own pool of cookies to store, then that implies only 3 or 4 users can really be on at once. Why only 3 or 4? Google Analytics puts 4 or 5 more cookies as well. (Other tracking software is bound to put them on as well). The tracking cookies are a low priority, except if they are preventing users from getting to the site.

    Like

  5. Re: continued…
    You’re welcome….hopefully someone (anyone?) will lend a “hand” soon…
    This usually means that the cookie sticks around until the web browser is closed and then is purged. AOL, however, keeps session cookies until the client is closed in its entirety. In other words, despite closing all the internal web browser windows within your AOL client, all session cookies received in the current session will remain resident.
    OK, this part I can understand, since I know how the AOL client works. It’s just a web browser that you happen to be able to sign into and out of, and that can actually establish and stop Internet connectivity for you. Many other ISP’s client software includes the sign-on and sign-off features, obviously, but as far as I know, AOL’s client is the only one that can actually establish and stop Internet connectivity for you. That makes it unique among web browsers and dial-up clients.
    So when they write in their Q/A: “This usually means that the cookie sticks around until the web browser is closed and then is purged”, they’re actually blaming themselves for an issue that is not unique to their own client; that’s no different than, say, how Firefox works. In Firefox, I could close this LiveJournal page (without signing out) and re-open it in a new window a few minutes from now: I would still be logged into LJ. I’d have to close Firefox completely (and additionally, perhaps toss my cookies) to completely end my session with LiveJournal.
    AOL isn’t doing things any differently; if I was to sign into LJ with the AOL client set to connect through dial-up right now (which I can’t because I don’t pay to use AOL and someone ripped my dial-up modem out of my PC last month, against my wishes), and visit my web page logged in, then close the page, and re-open it in a new window a few minutes from now, as far as I know, my session with LJ would still be active, but closing the AOL client would effectively end the session.
    That’s all I think AOL is saying, as far as I can tell, and I see nothing wrong with how that works. If you’re going to criticize them for that, then you have to criticize all web browsers and dial-up clients for pretty much the same behavior.
    I don’t know if you use persistent cookies on your website (it’s nice, BTW; checked it out this morning) or if you have prior experience with them, but here’s the difference between session and persistent cookies:
    LJ sets a session cookie which will expire when I shut the browser down and/or toss my LJ cookies. Threadsy.com (a recent example for me since I just started using it), on the other hand, sets a persistent cookie that remains active even after I close Firefox and re-open it five hours later, if I don’t go out of my way to toss the persistent threadsy cookie once I’m done on their site and close my browser.
    I’m saying all this just to make sure we have the basics nailed down before we move onto other stuff. πŸ™‚

    Like

  6. Re: continued…
    Just to back it up for a sec to answer your general questions about whether AOL caches cookies, on AOL’s Caching Info page they leave no room for doubt: unless you take steps to prevent it, your AOL user’s cookies will be cached with the headers.
    IMPORTANT NOTE: Cookies set in the HTTP headers of a cacheable object are also cached and served to members. Cookie values intended to be unique (customer id, session, id, etc.) should only be set with non-cacheable objects.
    As to “other” forms of tracking software on your website, I don’t see any. I only see Google Analytics (that’s using 2 add-ons: Web Dev and Ghostery and the Page Info in Firefox to check).
    While I was viewing your site info with Web Dev I saw you’re not serving any persistent cookies, so at least you have no worries of AOL users running into other people’s intentionally “sticky” cookies.
    As for your Session cookie, I’m wondering if you can use some sort of browser auto-detection to serve a unique cookie for AOL users only (so you’d always have one default cookie, but if an AOL client arrives, the attached AOL user gets a cookie all it’s own).
    That in itself wouldn’t solve the problem of how to make sure the cookie info doesn’t get passed from one AOL user to another; it would just sort of tie off AOL users so they could be dealt with separately.
    As to cookie limits, I’ll admit that there are some aspects of this issue that I never learned about, but I’m guess I’m going to now (it’d be nice to learn just to satisfy my curiosity). πŸ™‚

    Like

  7. Re: continued…
    Yes, we actually do use both sessions and cookies. πŸ™‚ For the most part cookies are best for long-term data that is meant to survive the browser turning off. The others that are set via my code are all persistent to allow them to return. This code has been in place for several years without changes and works/worked fine…I presume even for AOL users since none have complained before.
    I understand the browsers…and like the Firefox approach in nearly ever capacity. The AOL browser I would suspect would do the same. I don’t know how the AOL client differs from the AOL browser. I knew they were separate, but I don’t know how or where the client is stored… Client usually means the user’s active program, as cookies are usually stored on the user’s browser. I was worried that the client was on the proxy…just like the cache and cookies. With the proxy servers, is the client on the user’s PC or on the proxy server? If it is the proxy server, that would be bad because the session cookies would never clear until the cache is flushed…which would point user to sessions from other users…maybe. If the user’s PC has it, that is okay. Then “signing out” or closing the client would be the same as Firefox and IE. πŸ™‚
    In short, the cookie stores the long-term storage of the users to log them back in when they return. The session variables within the session (and hopefully using the Session ID stored in session cookie to match up the user to the session) are used to keep track of user progress within a log-in session…like items in cart, name, forum setting, etc. Otherwise, we have to store all this in cookies and would quickly run out. We just pull it from the database once we know what user we are dealing with… We use the cookie to identify the user, then use superglobal variables as needed to manage the session. I have code that attempts to login users in automatically IF they have a cookie on the system. Since the code has not changed in years, I am running out of possible suspects for why it would suddenly “stop”.
    I am aware that (in a non AOL world at least) that the session is gone when the browser is closed. This is also good. They can exit our site and come back later with the session still active, but closing the browser kills the session (and hopefully the session ID as well since the session is gone). For example, our cart system is set to drop the cart when the session is no longer active. Having the cookie is what logs our users back in. The session variables get filled once the login process is complete, and users (should) see only their products and services and general content that is accessible. For AOL, they are suddenly (within the last two weeks or so ???) seeing other users’ info at random. We do not think this has been happening until recently, but are not sure???
    It is definitely good to start with the basics though, so no problem with you reviewing them. And for others reading this posting, they will know we covered the base and can provide the Virtual hand.
    Hopefully, this info helps clarify the situation. Both cookies and sessions can work together. Has anybody noticed this problem… perhaps since the last AOL update around Dec 17th? {I looked that up yesterday…and a light bulb went off. Of course, I wouldn’t swear that the update is to blame –it just happens to correspond with the problem.}

    Like

  8. Re: continued…
    Small Edit:
    For AOL, they are suddenly (within the last two weeks or so ???) seeing other users’ info at random. We do not think this has been happening until recently, but are not sure???
    above could be misinterpreted….so it should be:
    For AOL, they are suddenly (within the last two weeks or so ???) seeing other users’ info at random,
    but all happen to be AOL users. We do not think this has been happening until recently, but are not sure???
    They are not seeing randomly any user, just other AOL users. This goes back to the first part and my example that you helped me clarify why. If it was from any user, that would imply bigger problem…and probably defend AOL. πŸ™‚ But so far, only AOL users are having this issue and seeing other AOL users’ info. Hoe that clears that up. πŸ™‚

    Like

  9. Re: continued…
    Well, this might be neither here nor there, but I just got done reading this, which seems to indicate that 1) the now-defunct AOL OpenRide browser acts as an open proxy server by using AOL proxy addresses regardless of which ISP you use ( I don’t think I knew that, which surprises me, but I did know – and I’ve even written about how – you can use AOL in general to such purposes), and that AOL “now” assigns static IPs (only per session) to AOL users that are now viewable by a webmaster – but I’m not sure if that applies only to Wikipedia, which AOL was working with at the time toward a solution to AOL defacers on their website, or to all websites (edit: just Wikipedia; I had to re-read a certain paragraph to make sure). I’ll post more in a bit…
    OK , I’m back…so what I was thinking is, just to prevent these sort of cookie mix-ups in the future, since your site is huge, popular, and well-trafficked, if nothing else, could you set up the same sort of agreement AOL has with Wikipedia yourself, so AOL can send you the special X-Forwarded headers that allow you to see and target individual (that is, actual, not proxy server) IPs more precisely? That would help, wouldn’t it, if you could pull that off?

    Like

  10. Re: continued…
    After registering at your site I got this warning very briefly on my screen (it lasted on-screen maybe half a second? It flashed by, then the next page that I was on my way to when I saw it loaded normally – I copied and pasted it from the top lines of your source- not sure why it’s in there, but maybe it’s just nothing):
    Warning: Cannot modify header information – headers already sent by (output started at /home/memo/admin/html/generator/feeder_admin_fun.php:39) in /home/memo/www/includes/functions/forum/forum_login.php on line 25
    Warning: Cannot modify header information – headers already sent by (output started at /home/memo/admin/html/generator/feeder_admin_fun.php:39) in /home/memo/www/includes/functions/forum/forum_login.php on line 26
    ETA: Just to keep everyone else from getting lost, the errors are not part of the problem; see this reply.

    Like

  11. Re: continued…
    Oh no, we only use Google Analytics, but I suspect most tracking software uses some type of cookies. Google always stores up to five on our site. The cookies are named “__utma”,”__utmb”,”__utmc”,”__utmx”,”__utmz”. This was in reference to the number of cookies each site can store. They track first visit, first and last visit duration, etc… They are no problem accept if the limit on cookies means they will cancel out our normal user cookies or block them.
    The same site (http://webmaster.info.aol.com/aboutcookies.html) confirms the general limits “Each browser can accept up to 20 cookies by a single web server and can have as many as 300 cookies total on file at any one time.” However, if cookies are on the proxy, it would mean a limit of 20=4 or 5 users for any AOL user(s) at a time. If stored on the client user’s machine, no problem, that is how most browsers work.
    The persistent cookies are set if you are logged in. As a visitor, I don’t think they are ever set. If you want to see them, feel free to create an account and register…don’t worry you don’t have to buy anything. Once you log in, you should see three more that have very long expiration dates set. I have 7 cookies right now and have not even done anything yet. Three at the moment from Google, the session ID, the forum log-in and the user/pass set. The last three are all persistent. The session ID and Google are all session cookies only.
    However, I agree that cookies may not have anything to do with it. It might simply be using a page (from cache) that happened to be loaded with another user’s info. Since it does not re-validate without the special header, it would make sense.
    Wish me luck: I am going to try that code segment anyway. If I start using the header (for no-cache) now, will I have to wait until the AOL proxy flushes the cache to see it fully take affect?

    Like

  12. Re: continued…
    Hey, this is funny that we keep writing and posting at about the same time…multiple times.
    Those errors do not block the user at all. This is because the new cookies are created after most of the page is processed. Your login is still valid. You can go back to the home page and login…if you haven’t already…and the cookies should be present. I’ll get rid of these two later, but you won’t see these again. Registration is the only time they pop up. πŸ™‚ I’ll remove those as soon as time permits.
    It might be worth trying to see if AOL will share with us. Though I do not think we are on the scale for AOL to consider us big or highly used. It would be nice, but I think they would still think of us as infants.
    I am going to try the code for the header and see what happens. Once you log in, did/can you see the cookies?

    Like

  13. Re: continued…
    Don’t know if you saw this yet:
    http://anti-aol.livejournal.com/118039.html?replyto=311575
    But I think (I’m not sure, of course, it’s simply my best guess for the moment) that that might be your problem. I don’t know when your site started delivering that error message (that is, was it before or after you began tinkering with the code again today?), but I registered in Firefox about an hour to an hour and a half ago (just minutes before I wrote the comment where I said I’d “be back in a bit”; if you want to look my registration up in your logs, I chose a Rodeo Drive address (not where I live, but it’s easy to remember); I can’t recall which username I chose, either – *but*, I registered again with a different user name in IE (sarah1) a few minutes ago just to establish that the header error messages are 1) cross-browser 2) persistent 3) happen only right after one registers and 4) affect AOL, which they obviously do, since the AOL client uses the Trident rendering engine, same as IE does. If you could get back to me on what the error message is about and whether you think it might be screwing up your AOL users, that might help.
    BTW, sorry to make confusion with my “client” vs. “browser” terminology: to distinguish various AOL software products, I call the AOL browser “the client” because for one, most people who work with it, test it, code for it, etc., do, and for the other, because it helps me to distinguish it from the AOL browsers such as Open Ride and Explorer (I guess some people still use them, though both browsers are officially dead). The AOL “client” includes it’s own dial-up connectivity software; the other AOL browsers don’t. That’s all. Actually, that’s not all, but just to keep it simple… πŸ™‚
    Edit: OK, got your reply below that the error messages about headers aren’t the problem – thanks for clearing that up.

    Like

  14. Re: continued…
    I am going to try the code for the header and see what happens. Once you log in, did/can you see the cookies?
    No. I only saw the original session cookie. I don’t have such add-ons installed right now, but do I need LiveHTTP Headers, or TamperData, or some other sort of add-on that I don’t have at the moment installed to see the new/additional cookies? I can’t see any after registration/sign-in using Web Dev, Page Info, or any other method (I guess I could go through my cookies manually – that’s the only other thing I haven’t tried yet).
    Using Web Dev I just got the cookies: there’s 3, correct? I closed the page, re-opened it, and my session had expired, so I logged in as sarah1 (the profile I created in IE) and there they were. I don’t know why they didn’t show up after I registered my first username in Firefox; there’s not supposed to be a delay, right?
    ETA: Just out of curiosity…the session cookie is set to expire, obviously, at the end of the session; the other two cookies are set to expire on Dec 24th – 5 days ago – is there any reason for that?

    Like

  15. Re: continued…
    No, they don’t, not as a general rule. Like I said in my edited comment above, that’s only for Wikipedia, through an agreement AOL made with them to send along X-Forwarded headers to help weed out the defacers.

    Like

  16. Re: continued…
    No problem. The error message is caused by sending output after the header. Normally, no output is sent until the page is completely composed in PHP with all of the little components. Each page is about 40-47 technical HTTP requests…which is why the IP switching and sessions worry/worried me. On the new registration page, I load the page, process the login only after confirmed by user and generate the cookies from here to start the session. Of course, these are not sent because the forum login code is after output has been made. This is the only page where the processing order required the cookies made after output. All the registration repeats as planned, but the cookies are not made. No shock, just an old gliche that has been there for quite a while. I will make a note to remove it. πŸ™‚ I rarely make new registrations. Thanks you. πŸ™‚
    When users go to log in, the validation and cookies get made before output, so no error messages. From then on, you should see the normal cookies, three of which are in the future.

    Like

  17. Re: continued…
    Cookies are sent in the header the next time a page is loaded, so there is a small delay. Some people try to use the cookie before it is created and stored. This is a common mistake that does get made. But you browser is right.
    I used Firefox to make a new one and had no problems (except for the error messages you saw). I only have one registration for you. Three cookies is correct (for persistent at least).
    I added the code for the header. Cross your fingers. πŸ™‚

    Like

  18. Re: continued…
    Definitely neither here nor there, but you’re storing my password in plain text in one of my cookies. Is that, like, the industry-standard way to do it (I swear I’ve never spent this much time looking at cookies before in my life)?
    And yes, good luck… πŸ™‚

    Like

  19. Re: continued…
    Actually, it should be Dec 24th of 2029…30 years in raw days (no leap years) from now… The goal is to not force them to log in if they don’t want to remember it.
    The password thing is temporary to test to see if the password was being stored correctly.

    Like

  20. Re: continued…
    Yes, my bad. I didn’t look at the year too carefully. I just saw, “Dec 24th,20-” and I stopped right there and looked at the next cookie…
    The password thing is temporary to test to see if the password was being stored correctly.
    It’s storing the password correctly. I promise you, it is. πŸ™‚

    Like

  21. Re: continued…
    After looking at your response headers in Web Dev, then comparing what you have in them with what you could have in them, I read this. Although the advice given isn’t for your exact situation (your pages are not “private”), I was looking this answer over and wondering if it might work regardless of whether your pages are private or public.
    My pages are password-protected; how do proxy caches deal with them?
    By default, pages protected with HTTP authentication are considered private; they will not be kept by shared caches. However, you can make authenticated pages public with a Cache-Control: public header; HTTP 1.1-compliant caches will then allow them to be cached.
    If you’d like such pages to be cacheable, but still authenticated for every user, combine the Cache-Control: public and no-cache headers. This tells the cache that it must submit the new client’s authentication information to the origin server before releasing the representation from the cache. This would look like:
    Cache-Control: public, no-cache

    I’m thinking it’s a close-but-not-quite answer.
    Oh, and I wasn’t done yet, but I logged into LastPass after writing that last sentence and didn’t expect it to publish my comment while it was at it.
    I haven’t even begun to check the Web yet for the AOL update problem. I have to wonder if the updates are pushed through globally (to all versions of the AOL client) or if only some (or just one) version number(s) are/is affected, which would complicate things even more if the update itself is responsible for your AOL user’s woes.
    I also want to check the Web for what other web devs do when they run into cookie mix-ups with AOL users, so I’m not done trying to piece this together yet.

    Like

  22. Re: continued…
    That is actually one of the differences between the header used and the new one. “private”. The other added item to the headeer code is “proxy-revalidate” which is separate from the other revalidate piece.
    My guess is that all the “supported” versions are updated. Whether or not the user has to do anything is unknown. Firefox is up to the user. IE comes with your Windows Updates. Chrome at least seems like you have to allow it like Firefox. AOL could do either and have it be normal.

    Like

  23. I don’t know how “ΠΆΠ³Ρ‘Ρ‘Ρ‹Ρˆ” got in there…that’s from a comment many pages back from here.
    And I *do* know how it got in there. I need to just get rid of my LastPass add-on. It stores all kinds of information with my logins that I did not ask it to store, including the titles of replies and so on.
    I’ll check your new headers out…and good luck. I saw your post on Webmaster World tonight while looking for anyone else’s solution to the problem (but I can’t even find the problem out there – you seem to be unique in that your AOL users are actually passing their cookies to each other in reality, not just in theory) and I’m surprised no one has responded there either…a couple of years ago, you would have gotten some responses, I think…but nowadays (it’s almost 2010, and people *still* use AOL?) I think most web devs just give up – they’d rather lose AOL users than go through all the crap with coding headers and handling cookies just to keep them.

    Like

  24. Re: I don’t know how “ΠΆΠ³Ρ‘Ρ‘Ρ‹Ρˆ” got in there…that’s from a comment many pages back from here.
    I would be delighted to ignore AOL, if it weren’t for the fact that we have good clients that have been with us for a while. Too bad using Firefox thru AOL didn’t work…. But I think I will be able to gage if it worked tomorrow, once AOL clears the proxy cache and AOL users start getting new headers. However, since it does not always happen, I might have to wait a week or so before concluding that it worked.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s