In Firefox 1.5.0.6 with cookies set to 'Ask Everytime'

if I key the link in directly into firefox, & will not set the cookie
If I key the link in directly with & rather than &, it will set the cookie
If I cut and paste a link from a page set with a doctype of transitional, it works.
If I cut and paste a link on a doctype set with strict and the url not contained within CDATA (in other words, a page that won't validate) , the cookie is not set.

Additionally, if the link is coded through a script and sent as:

it will not set the cookie because the location header that 99% of the tradescripts are using doesn't de-entify before sending to ccbill.

IE exhibits some odd behavior depending on which version you use. 5.5 does not deentify before sending in my tests. 6.0 does most of the time, but, failed once. I believe ccbill should set the cookie each time regardless of whether there is already a cookie present for that master account number, but, that isn't what I observed in one of the tests I did above. And after it happened, I couldn't duplicate it.

According to the RFC, the browser is supposed to deentify when going to a url, but, clearly when you cut and paste a url into firefox, there is no way for firefox to guess what action it should take.

Personally, I wouldn't want to rely on the browser guessing at what is supposed to happen.

Just to clarify you are talking about browser problems deentifying when copying and pasting entities directly to the address bar and not when links are clicked on a page?

if a surfer right-clicks on a url on a page and pastes it into their browser, depending on a few different factors, they can get the entified or deentified link.

Since there is some inconsistency there, or, when used in trade scripts, etc, it just seems to me that better safe than sorry would be the rule of thumb. Especially since IE 5.5 also seems to exhibit the behavior even on clicked links.

Has anyone talked to a ccbill rep on this?

Everyone is blaming their text editors for encoding ampersands when really that's what they should be doing. I think it's ccbill that needs to address this on their end. Would it be that hard credit links with encoded ampersands?

Going through all our links looking for encoded ampersands seems like a lot of unnecessary work especially considering that that's the way they should be written.

Given time and exposure this may even hurt pay sites as webmasters might choose to not bother with sites that use referral links in this "risky" format.

I am very newbie so please be gently.
Question is
can I change the code (replace & with just &) on existing submitted free sites and then upload it to server? Will I be banned for this?

I have found several affected links to sponsor on my sites.

Thank you
Bertik

I did that in the past with no problems.

I'd like to hear what ccBill has to say about it.|catfight|
I have found a few PPC linksthat ended up with the encoded amp. It seems to be only some links that I have gone back and modified though.|club|

Same here. I guess those nifty html editors don't like creative construction of urls. |loony|

Actually I was referring to their online maintenance systems. Probably in PHP or CGI.

Ya lost me... whose maintenance system? |confused|

A few of the PPC advertising programs have a small problem with encoding the links if you have gone back and change the links.

I never have this problem in normal html since I use a text editor, but i do have it in wordpress posts. Anyone knows a solution to that?

Modify your wordpress now, and every time you update? |huh

I'm not sure I understand what you mean virgohippy