Error with client-side XSL transformations while switching from HTTPS to HTTP

[Tony Marston]

I have a demo application on my website at http://www.radicore.org/demo.php
in which at HTML is built using XSL transformations. The page contains 2
links:

http://www.radicore.org/demo/menu/logon.php for server-side transformations
http://www.radicore.org/demo/menu/logon.php?csxslt=on for client-side
transformations

The first page is a login page which has to be run via a secure server, so
it issues a redirect to
https://rocket.secureguards.com/~radicore/demo/menu/logon.php

If the logon credentials are correct the logon page redirects to
https://rocket.secureguards.com/~radicore/demo/menu/menu.php, but as this
does not require a secure server it is immediately redirected to
http://www.radicore.org/demo/menu/menu.php Unfortunately when trying to
display this menu page all I se is the following error:

The XML page cannot be displayed

Cannot view XML input using style sheet. Please correct the error and then
click the Refresh button, or try again later.

Access is denied. Error processing resource
'https://rocket.secureguards.com/~radicore/demo/menu/logon.php'.

The URL being show is http://www.radicore.org/demo/menu/menu.php and not
logon.php. Also, when using the "view source" option I can see the entire
XML document which is perfectly valid. This is strange as the "view source"
option normally does not work after the client-side XSL transformation has
been performed.

If I tell my application not to use a secure server then it can move from
logon.php to menu.php without any problems.

This error only occurs with IE and not FireFox, so it is an IE problem.

Does anyone have any clues?

 

[Robert Aldwinckle]

This error only occurs with IE and not FireFox, so it is an IE problem.

Have you tested using IE7? Any change?

Does anyone have any clues?

FWIW I used IE7 to open this

does not require a secure server it is immediately redirected to
http://www.radicore.org/demo/menu/menu.php

and was redirected here

https://rocket.secureguards.com/~ra...73d0235b248eab9e99be473f6a9&session_name=menu

which looked fine but of course I can't test the Login feature.


HTH

Robert Aldwinckle
---

 

[Tony Marston]

...



Have you tested using IE7? Any change?

No. I do not load beta software onto my PC.

FWIW I used IE7 to open this


and was redirected here

https://rocket.secureguards.com/~ra...73d0235b248eab9e99be473f6a9&session_name=menu

which looked fine but of course I can't test the Login feature.

That is because I had to disable the secure server when performing
client-side XSL transformations with IE in order to make that part of my
site work. If you care to supply me with your IP address I can selectively
turn it back on so that you can test it.

 

[Robert Aldwinckle]

....

That is because I had to disable the secure server when performing
client-side XSL transformations with IE in order to make that part of my
site work. If you care to supply me with your IP address I can selectively
turn it back on so that you can test it.

I'm on dialup so I don't get a fixed IP address.
I could use the password reminder feature if you want to authorize
my E-mail address? It's a fairly reliable webmail address.
As long as the Subject catches my eye I read stuff it receives.


Robert
---

 

[Tony Marston]

...


I'm on dialup so I don't get a fixed IP address.
I could use the password reminder feature if you want to authorize
my E-mail address? It's a fairly reliable webmail address.
As long as the Subject catches my eye I read stuff it receives.

I think it's easier if I reinstate the secure server for everybody. Try it
now and you should see the error.

 

[Robert Aldwinckle]

....

I think it's easier if I reinstate the secure server for everybody.
Try it now and you should see the error.

Indeed! I'm wondering if the fact that it is non-cacheable
will have any bearing?

<extract from="Fiddler">
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
</extract>

Also, ICIM I have unchecked (in Options, Advanced tab, Security section)
/Do not save encrypted pages to disk/
IOW *save* encrypted pages to disk (provided they are cacheable. <w>)

Having that option checked, which may be a default has been known
to cause problems for save XML based web apps such as the
Security Bulletin Search tool.


Robert
---

 

[Tony Marston]

...


Indeed! I'm wondering if the fact that it is non-cacheable
will have any bearing?

<extract from="Fiddler">
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
</extract>

I've tried turning off those options, but the result is still the same.

Also, ICIM I have unchecked (in Options, Advanced tab, Security
section)
/Do not save encrypted pages to disk/
IOW *save* encrypted pages to disk (provided they are cacheable. <w>)

I have also tried toggling this option ON and OFF, but te result is still
the same.

 

[Robert Aldwinckle]

I've tried turning off those options, but the result is still the same.

Did you make sure that it turned up in the TIF after you did that?

In any case, even though it is non-cacheable FileMon can show you where
menu[1].xml is going in the TIF.

Hmm... Maybe I wasn't looking at the right file. Is it the menu.xml file that
is the problem or the menu.xsl file that the menu.xml file uses?
I saved the menu.xml to My Documents and I get a problem symptom
when I try to open it.

<example>

System error: -2146697208. Error processing resource 'http://www.radicore.org/demo/xsl/menu.xsl'.

</example>

<blush/> I tried that with Work Offline set. Once I set it back Online
your styleheet was used successfully.

However, FileMon showed absolutely no sign of an .xsl file.
Oh. Apparently the .xsl file shows in FileMon and is stored in the TIF
as .xml Even stranger the .xsl file is cached somewhere because
your server returns "Not Modified". I wonder where IE is finding it?
I just had FileMon filtering on Temp thinking that that would capture
anything being written in the TIF. It did. I was getting confused I think
because both files will be stored as menu.xml in the TIF.

Darn. I wasn't even thinking of that when I had Fiddler open
and now it's gone and your server is down? (not responding anyway.)

In any case, I now see that Fiddler won't be able to show me it anyway
because the protocol is https. I would only be able to infer which transaction
it was based on what FileMon was writing. In that case I guess you would
have to use Winhttptracecfg (or set the equivalent registry values it changes)
Ref KB307272 or try the one in the XP RK which seems more recent.

FWIW I tried using this combination of options but I can't see that it
created or added to anything:

winhttptracecfg -e 1 -l radicore -d 0 -s 1 -t 1

I vaguely remember having a similar problem before but can't remember
what circumstances finally allowed a trace file to show up.

However, all this analysis has given me another idea for you anyway.

Fiddler is showing that menu.xml will be requesting menu.xsl
which as I mentioned is cached. Content.IE5\index.dat even shows
its protocol as being http:// But when was it cached? My guess is it
happened somewhere in those transactions on port 443. Even if a
trace doesn't show that explicitly I'm wondering if perhaps you should
try modifying your XML header to point at an https: instance of the
menu.xsl file instead?

Also, does Firefox provide any better diagnostics for its case?
If so, perhaps you can get some insight from them for IE's case.


Good luck

Robert
---

 

[Tony Marston]

Did you make sure that it turned up in the TIF after you did that?

I think that is a red herring. The logon.php page is successfully processed
over HTTPS, then it redirects to menu.php which redirects itself from HTTPS
to HTTP. The address bar correctly shows
http://www.radicore.org/demo/menu/menu.php and fiddler shows that the
correct XML document is present, yet the error message is incorrectly
reporting a problem with
https://rocket.secureguards.com/~radicore/demo/menu/logon.php. Somehow the
switch from HTTPS to HTTP has caused IE to lose track of which URL it is
supposed to be processing.

In any case, I now see that Fiddler won't be able to show me it anyway
because the protocol is https.

Try loading the RPASpy plugin then you will be able to see all HTTPS
headers.

I would only be able to infer which transaction
it was based on what FileMon was writing. In that case I guess you
would
have to use Winhttptracecfg (or set the equivalent registry values it
changes)
Ref KB307272 or try the one in the XP RK which seems more recent.

FWIW I tried using this combination of options but I can't see that it
created or added to anything:

winhttptracecfg -e 1 -l radicore -d 0 -s 1 -t 1

I vaguely remember having a similar problem before but can't remember
what circumstances finally allowed a trace file to show up.

However, all this analysis has given me another idea for you anyway.

Fiddler is showing that menu.xml will be requesting menu.xsl
which as I mentioned is cached. Content.IE5\index.dat even shows
its protocol as being http:// But when was it cached? My guess is it
happened somewhere in those transactions on port 443. Even if a
trace doesn't show that explicitly I'm wondering if perhaps you should
try modifying your XML header to point at an https: instance of the
menu.xsl file instead?

That wold not work. I discovered some time ago that the XML file and the XSL
file it uses for the transformation must both be sent with the same
protocol, so if the menu.php page is delivered over HTTP then the XSL file
must also be delvered over HTTP.

The probem is that IE is receiving the URL for menu.php over HTTP but
reporting a problem with logon.php over HTTPS. It is getting its knickers in
a real twist.

Also, does Firefox provide any better diagnostics for its case?
If so, perhaps you can get some insight from them for IE's case.

The switch from HTTPS to HTTP does not fail in Firefox when performing
client-side XSL transformations, so there is no problem to diagnose.