Mysterious Problem

[Juergen Ebert]

Imagine a e-commerce site which handles payment through a
third-party-service. This is done by including an IFrame (payment) in
the shop application. Both the IFrame content and the shop are secured
by HTTPS but of course with different certificates. When the payment is
done the third-party-service sends some kind of redirect so a "Payment
was successful"-page from the shop is again shown in the browser as
IFrame content.
This is where the fun (!?) starts. When using IE6 with "friendly error
messages" activated the user will not see the "Payment was
successful"-page but the standard "The page cannot be displayed" error
page. However if the same user disables the "friendly error messages"
then no error will be shown but the "Payment was successful"-page will
be displayed whithout any indication of a problem.
With other words the error page will only be displayed if using
"friendly error messages" but everything will work ok if not.
Unfortunately not all users are affected, most users do not see any
error at all. Needless to say that users of other browsers also do not
see errors.

Interestingly the users who get the "The page cannot be displayed"
message will be asked before if they wish to display nonsecure items in
this otherwise secure page. I came to think that the error page itself
is the nonsecure item since it comes from the local filesystem (either
about: or res. Right?

To determine where the problem might be we put some debug output into
the "Payment was successful" page and this code is excuted for those
users who see the error page. So the redirect from the payment system
seems to work. Looking into the data sent seems to be difficult because
of the HTTPS protocol so we don't know where else to look.

Now I need to know if this is a known bug in IE. It also would be
helpful to know what triggers IE to display the "The page cannot be
displayed" error page. Only the http return code? Something else?
What else can we do determine the cause of this problem?

Regards,
Juergen Ebert

 

[Robert Aldwinckle]

....

Looking into the data sent seems to be difficult because
of the HTTPS protocol so we don't know where else to look.

Juergen,

See if this gets you any further:

<title>KB307272 - How To Trace ServerXMLHTTP Calls Using the Winhttptracecfg Tracing Tool in XML</title>

BTW I have not tried it myself but I am having some trouble myself
with the Windows Update Catalog so that may be my impetus to
start using this tool. Netcap and Ethereal seem not to be enough
for diagnosing problems which involve secure protocols.


Good luck

Robert Aldwinckle
---

 

[Juergen Ebert]

Robert,

Thanks for the advice. Unfortunately I don't seem to get it working. The
KB article says "Restart IIS" and we do not use IIS. So I tried it on
the client side anyway but after I enabled the logging no log files
where created. I restarted the machine and now I got a log file for
svchost.exe and one for winlogon.exe. Both files contain a log entry
which basically says that the process was started. Opening IE and going
to websites does neither create another log file nor another entry in
one of the existing files.

Regards,
Juergen Ebert

 

[Robert Aldwinckle]

Robert,

Thanks for the advice. Unfortunately I don't seem to get it working.

Juergen,

I thought so too but just discovered a bunch of trace output files
on my Desktop! ;o

It's pretty sketchy. I would suggest you use it only to supplement
a netcap trace and see from that comparison what additional detail
it provides. It looks as if the most useful capability it has is to allow
tracing some API calls with their parameters and return codes.


HTH

Robert
---