Unicode version of FindFirstUrlCacheEntry

Discussion:

(too old to reply)

2007-12-10 21:06:06 UTC

Hi there,

Here is the scenario (for XP machine):

I have an user whose username is: joséna

I have a C++ app that uses FindFirstUrlCacheEntry/FindNextUrlCacheEntry to
enumerate thru IE cookies.

The ANSI version of the API has no problems and returns her username
correctly:
lpszSourceUrlName = "Cookie:josé***@somesite.com"

But with IE7 and Unicode version of these APIs, the return value is:
lpszSourceUrlName = "Cookie:***@somesite.com"

so, for some reason the character "é" is gone and when using
DeleteUrlCacheEntry this will cause this API to fail because the entry
doesn't exist without the "é"...

Can please someone let me know if there is a workaround? or if I am doing
something wrong...

Thanks

Volodymyr Shcherbyna

2007-12-11 09:58:08 UTC

Permalink

I will contact WNDP team regarding this issue.
--
Volodymyr

Post by HT
Hi there,
I have an user whose username is: joséna
I have a C++ app that uses FindFirstUrlCacheEntry/FindNextUrlCacheEntry to
enumerate thru IE cookies.
The ANSI version of the API has no problems and returns her username
so, for some reason the character "é" is gone and when using
DeleteUrlCacheEntry this will cause this API to fail because the entry
doesn't exist without the "é"...
Can please someone let me know if there is a workaround? or if I am doing
something wrong...
Thanks

htome

2007-12-11 14:04:12 UTC

Permalink

Sorry, problems with the editor...it should read:

The ANSI version of the API has no problems and returns her username
correctly:
lpszSourceUrlName = "Cookie:josé***@somesite.com"

But with IE7 and Unicode version of these APIs, the return value is:
lpszSourceUrlName = "Cookie:***@somesite.com"

I also had the problem with a French user with username
"propriétaire"...the Unicode version is retrieving:
lpszSourceUrlName = "Cookie:***@somesite.com"

Extended characters are not being properly handled by the Unicode
version of APIs.

On Dec 11, 4:58 am, "Volodymyr Shcherbyna"

Post by Volodymyr Shcherbyna
I will contact WNDP team regarding this issue.
--

- Show quoted text -

2007-12-12 01:55:55 UTC

Permalink

in the attempt to fix the problem, I went ahead and assembled the string
manually so I could use DeleteUrlCacheEntryW but for my surprise it also has
a bug/problem...

if I try to use an Unicode string like "Cookie:josé***@somesite.com" with
DeleteUrlCacheEntryW, it fails to delete

but if I use DeleteUrlCacheEntryA with a ANSI string (naturally) then it
works...

So, because my app is Unicode, I had to manually assembled the string,
convert it to ANSI and use with DeleteUrlCacheEntryA to make this works...

Well, I will wait for you findings with WNDP...

Thanks

Post by Volodymyr Shcherbyna
I will contact WNDP team regarding this issue.
--
Volodymyr

Post by HT
Hi there,
I have an user whose username is: joséna
I have a C++ app that uses FindFirstUrlCacheEntry/FindNextUrlCacheEntry
to enumerate thru IE cookies.
The ANSI version of the API has no problems and returns her username
so, for some reason the character "é" is gone and when using
DeleteUrlCacheEntry this will cause this API to fail because the entry
doesn't exist without the "é"...
Can please someone let me know if there is a workaround? or if I am doing
something wrong...
Thanks

2007-12-12 01:58:34 UTC

Permalink

Post by Volodymyr Shcherbyna
I will contact WNDP team regarding this issue.
--
Volodymyr

Post by HT
Hi there,
I have an user whose username is: joséna
I have a C++ app that uses FindFirstUrlCacheEntry/FindNextUrlCacheEntry
to enumerate thru IE cookies.
The ANSI version of the API has no problems and returns her username
so, for some reason the character "é" is gone and when using
DeleteUrlCacheEntry this will cause this API to fail because the entry
doesn't exist without the "é"...
Can please someone let me know if there is a workaround? or if I am doing
something wrong...
Thanks

Volodymyr Shcherbyna

2007-12-12 07:12:00 UTC

Permalink

Actually, in 90 % of cases UNICODE versions of wininet functions call ANSI
equivalents. Here is a related post to this topic:
http://msmvps.com/blogs/v_scherbina/archive/2006/07/07/Finally-Microsoft-implemented-InternetReadFileExW-function-_2E002E002E00_.aspx
--
Volodymyr

Post by HT
in the attempt to fix the problem, I went ahead and assembled the string
manually so I could use DeleteUrlCacheEntryW but for my surprise it also has
a bug/problem...
DeleteUrlCacheEntryW, it fails to delete
but if I use DeleteUrlCacheEntryA with a ANSI string (naturally) then it
works...
So, because my app is Unicode, I had to manually assembled the string,
convert it to ANSI and use with DeleteUrlCacheEntryA to make this works...
Well, I will wait for you findings with WNDP...
Thanks

Post by Volodymyr Shcherbyna
I will contact WNDP team regarding this issue.
--
Volodymyr

Post by HT
Hi there,
I have an user whose username is: joséna
I have a C++ app that uses FindFirstUrlCacheEntry/FindNextUrlCacheEntry
to enumerate thru IE cookies.
The ANSI version of the API has no problems and returns her username
so, for some reason the character "é" is gone and when using
DeleteUrlCacheEntry this will cause this API to fail because the entry
doesn't exist without the "é"...
Can please someone let me know if there is a workaround? or if I am doing
something wrong...
Thanks

2007-12-12 14:29:58 UTC

Permalink

Hi Volodymyr,

So, this suggests that instead of waiting for MS, I should go ahead and use
my kludge that calls the ANSI version whenever DeleteUrlCacheEntryW fails...

Anyway, please, let me know if you ever heard from them or if you have a
better solution...

Many thanks!!!

Post by Volodymyr Shcherbyna
Actually, in 90 % of cases UNICODE versions of wininet functions call ANSI
http://msmvps.com/blogs/v_scherbina/archive/2006/07/07/Finally-Microsoft-implemented-InternetReadFileExW-function-_2E002E002E00_.aspx
--
Volodymyr

Post by Volodymyr Shcherbyna
I will contact WNDP team regarding this issue.
--
Volodymyr

Post by HT
Hi there,
I have an user whose username is: joséna
I have a C++ app that uses FindFirstUrlCacheEntry/FindNextUrlCacheEntry
to enumerate thru IE cookies.
The ANSI version of the API has no problems and returns her username
so, for some reason the character "é" is gone and when using
DeleteUrlCacheEntry this will cause this API to fail because the entry
doesn't exist without the "é"...
Can please someone let me know if there is a workaround? or if I am doing
something wrong...
Thanks

Volodymyr Shcherbyna

2007-12-12 15:06:16 UTC

Permalink

I suggest you to wait for official response.

Both functions (FindFirstUrlCacheEntryW / FindNextUrlCacheEntryW) has its
own implementations, I mean they are not just delegating to ANSI
equivalents. This of course is logical, because the data might be lost. If
you will be able to reproduce the issue with the code, i.e. create a small
application that set's the cookie, and then retrieves it with losted
character - it will be great.
--
Volodymyr

Post by HT
Hi Volodymyr,
So, this suggests that instead of waiting for MS, I should go ahead and
use my kludge that calls the ANSI version whenever DeleteUrlCacheEntryW
fails...
Anyway, please, let me know if you ever heard from them or if you have a
better solution...
Many thanks!!!

Post by Volodymyr Shcherbyna
Actually, in 90 % of cases UNICODE versions of wininet functions call
http://msmvps.com/blogs/v_scherbina/archive/2006/07/07/Finally-Microsoft-implemented-InternetReadFileExW-function-_2E002E002E00_.aspx
--
Volodymyr

Post by Volodymyr Shcherbyna
I will contact WNDP team regarding this issue.
--
Volodymyr

Post by HT
Hi there,
I have an user whose username is: joséna
I have a C++ app that uses
FindFirstUrlCacheEntry/FindNextUrlCacheEntry
to enumerate thru IE cookies.
The ANSI version of the API has no problems and returns her username
so, for some reason the character "é" is gone and when using
DeleteUrlCacheEntry this will cause this API to fail because the entry
doesn't exist without the "é"...
Can please someone let me know if there is a workaround? or if I am doing
something wrong...
Thanks