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

"Juergen Ebert" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)
....
> 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
---

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

> 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" <(E-Mail Removed)> wrote in message
news:d21rho$opf$00$(E-Mail Removed)...
> 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
---


> 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
>
>> 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
>> ---
>>
>>
>>