History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: LPP-5742
Type: Bug Bug
Status: Closed Closed
Resolution: Not Laszlo
Priority: P0 P0
Assignee: Unassigned
Reporter: Elliot Winard
Votes: 0
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
OpenLaszlo

particular HTTP response fails in IE but succeeds in Firefox

Created: 09/Apr/08 04:50 PM   Updated: 11/Apr/08 08:24 AM
Component/s: LFC - Data
Affects Version/s: Freya
Fix Version/s: Cronus

Time Tracking:
Not Specified

File Attachments: 1. File BAD-HTTPS.lzx (0.9 kb)
2. File BAD-HTTPS.lzx (2 kb)


Severity: Minor
Fixed in Change#: 8,615
Runtime: N/A
Fix in hand: False


 Description  « Hide
0. load app over HTTPS
1. execute query to https URL that returns response encoded text/xml.
    <button text="make wonky call">
        <handler name="onclick"><![CDATA[
            var url="https://192.168.0.133:8443/webtop/dd?clientId=1207777501640&locale=&__lzbc__=1207777521937";
            canvas.getData(url);
        ]]></handler>
    </button>

    <method name="getData" args="src">
        ds.setAttribute("src", src);
        ds.doRequest();
    </method>

    <dataset name="ds" id="ds" />
    <handler name="ondata" reference="ds">
        Debug.warn("%w ondata %w", ds, ds.data);
    </handler>

2. wait for dataset ondata event to fire.

RESULTS:
observe error in debugger in IE. It works fine in Firefox.[1]
ondata does not fire. <--- this is the real problem. The debugger error is just a related indicator of the problem.
[2] is a dump of HTTP that triggers the warning.

[1]
WARNING: LzLoadQueue.XMLOnDataHandler load failed from URL 'https://192.168.0.133:8443/webtop/dd?clientId=1207777501640&locale=&__lzbc__=1207777521937', no data received.
WARNING: Failure to load data in serverless apps may be caused by Flash player security policies. Check your data server crossdomain.xml file

[2]
GET /webtop/dd?%5F%5Flzbc%5F%5F=1207777521937&null=&locale=&clientId=1207777501640 HTTP/1.1
Accept: */*
Referer: https://192.168.0.133:8443/pagan-deities/diamond/client/future/HTTPS/BAD-HTTPS.lzx?lzt=swf&debug=true&lzr=swf8
x-flash-version: 9,0,47,0
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: 192.168.0.133:8443
Connection: Keep-Alive


HTTP/1.1 200 OK
Cache-Control: private,no-cache,no-store
Content-Type: text/xml;charset=UTF-8
Content-Length: 54
Date: Wed, 09 Apr 2008 23:44:43 GMT
Server: Apache-Coyote/1.1

<error code="badrequest">malformed request xml</error>

 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Elliot Winard - 09/Apr/08 04:51 PM
+ test file

Henry Minsky - 09/Apr/08 06:36 PM
Was the main app loaded via a HTTPS URL, or HTTP? I have seen problems when trying to have a swf app which is loaded insecurely which tries
to load an HTTPS data request, or vice versa.

Elliot Winard - 09/Apr/08 08:06 PM
It's not really relevant that the response is an <error> XML node. The same error occurs with valid XML responses.

Elliot Winard - 10/Apr/08 04:57 AM
Main app must is loaded over HTTPS. Data is accessed over HTTPS.

Sorry this isn't a totally general testcase. 192.168.0.133 was my IP address. (I think that the proxy in Windows didn't like to show HTTPS to localhost).

Elliot Winard - 10/Apr/08 05:05 AM
updated test file shows that ondata fires in Firefox and not in IE

Elliot Winard - 10/Apr/08 05:56 AM
The same payload doesn't cause a problem is served as an XML call. I think it's something to do with the response headers.

André Bargull - 10/Apr/08 08:42 AM
Is it the stupid "https+IE" bug again? See my comment on LPP-1156.

Elliot Winard - 10/Apr/08 09:00 AM
Ugh. By doing the workaround noted at [0] the Flash player is able to process data with a Cache-ControL:no-cache HTTP header.

http://support.microsoft.com/default.aspx?scid=kb;en-us;272359

P T Withington - 10/Apr/08 09:04 AM
This seems relevant:

Basically an https request where the response says 'no-cache', IE will discard the date before the Flash player can read it.

Henry is testing this now.

[From http://support.microsoft.com/default.aspx?scid=kb;en-us;272359]

CAUSE
This problem occurs when the file is not cached on the client computer. There are several reasons why the file may not be cached:
? The user selects the Do not save encrypted pages to disk check box on the Advanced tab of the Internet Options dialog box.
? The server sends a Pragma:no-cache or Cache-control:no-cache header.
? If you are using Microsoft Internet Information Server (IIS), the Content-Expiration option is set to Expire Immediately, which sends no-cache headers as well as the Expires:0 http header.

RESOLUTION
To resolve this problem, perform the following steps:
1. In Internet Explorer, on the Tools menu, click Internet Options. On the Advanced tab, clear the Do not save encrypted pages to disk check box.
2. Make sure that the server does not send no-cache headers.
3. In IIS, in the Microsoft Management Console (MMC) snap-in, right-click the XML file. On the HTTP Headers tab, turn off the Content-Expiration option.


Henry Minsky - 10/Apr/08 09:27 AM
I put in a fix for this in the LPS server, which modifies the response headers we generate.

For the actual bug in this bug report, the situation was a SOLO app, so the server that they are talking to
will need to be modified to also send the appropriate cache-control response headers (or leave them out entirely)

------------------------------------------------------------------------
r8615 | hqm | 2008-04-10 12:24:46 -0400 (Thu, 10 Apr 2008) | 37 lines
Changed paths:
   M /openlaszlo/trunk/WEB-INF/lps/server/src/org/openlaszlo/utils/LZHttpUtils.java

Change 20080410-hqm-8 by hqm@badtzmaru.local on 2008-04-10 12:22:32 EDT
    in /Users/hqm/openlaszlo/trunk
    for http://svn.openlaszlo.org/openlaszlo/trunk

Summary: use different cache control headers to work around IE7 bug

New Features:

Bugs Fixed: LPP-5742

Technical Reviewer: ptw
QA Reviewer: (pending)
Doc Reviewer: (pending)

Documentation:

Release Notes:

Details:
    
Don't send Cache-Control: no-cache in the response header, because
IE7 will fail to read the HTTPS response properly.

Setting headers to
"Cache-Control", "cache, must-revalidate"
"Pragma", "public"

per suggestion on the net


Tests:

bug report test case works in IE (proxied mode)
test/lfc/data/alldata.lzx



------------------------------------------------------------------------
badtzmaru:trunk hqm$

Elliot Winard - 10/Apr/08 10:06 AM
this doesn't fix the problem, though.

Elliot Winard - 10/Apr/08 10:19 AM
we need to try to find a workaround that doesn't require user to change IE settings. Possible workarounds I can think of now is not sending no-cache header - but data in our application really should not be cached.

André Bargull - 10/Apr/08 10:30 AM
This is what I used to do in this case:
---
response.setHeader("Cache-Control", "no-store, private, max-age=0, must-revalidate");
response.setHeader("Pragma", "private");
---

Also see this document: "http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9"

Concerning the changeset: Shouldn't this be made configurable instead of hard-wired into the java-source?

P T Withington - 10/Apr/08 11:05 AM
My reading is that this is a bug in IE. I think the base problem is that IE does not want to cache 'secure' data (probably because they would store the unencrypted data on the disk, making it not so secure), but as a side-effect, the plug-in gets no data. So, basically, if you want your server to deliver data over https to a flash plug-in running in ie, you have to specifically tell ie to go ahead and cache it.

André's suggestion is different from what Henry used (seems like it might be better), but achieves the same end. In any case, you _have_ to adjust the headers that the server that is delivering up the data is sending. There is nothing we can do in the client to get data that IE will not give us.

Henry fixed our proxy server, but if you are running SOLO to some other server, you will have to fix that server.

[Henry and André's fix do not require the user to change any settings on his browser, assuming the user is using the default settings.]

P T Withington - 10/Apr/08 11:08 AM
Just to be clear: The bug is a microsoft explorer bug. Henry has worked around it in our proxy server. If you are using a SOLO app to some other server, that server will need a similar work-around.


Henry Minsky - 10/Apr/08 11:15 AM
If there is an issue with some advanced users who might have set advanced settings on their IE preferences, you could have
a webtop error dialog that pops up if the data is failing to load, and the browser is IE, and says "Possible problem with Internet Explorer, see this URL for instructions", and
point them to something explaining how to unset their options, and a link to the Microsoft bug report.

André Bargull - 10/Apr/08 11:47 AM
Should be documented somewhere in the devguide.

Elliot Winard - 10/Apr/08 12:53 PM
Andre's workaround works for us. Awesome.

Mamye Kratt - 10/Apr/08 01:30 PM
merged change r8615 into pagan-deities as r8616

Mamye Kratt - 10/Apr/08 02:07 PM
Closing

Elliot Winard - 11/Apr/08 08:24 AM
pragma should be private not public, right? For all those HTTP/1.0 browsers. (are there any HTTP/1.0 browsers left?)