Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 410157

Summary:

[ServerPush] ServerPush requests always return immediately in IE

Product:

[RT] RAP

Reporter:

Tim Buschtoens <tbuschto>

Component:

RWT

Assignee:

Project Inbox <rap-inbox>

Status:

RESOLVED FIXED

QA Contact:

Severity:

critical

Priority:

CC:

tbuschto

Version:

2.1

Target Milestone:

2.1

Hardware:

All

OS:

All

Whiteboard:

sr201

Attachments:

Description	Flags
quickfix	tbuschto: review?
Server-side solution	tbuschto: review+, rsternberg: review+

Description Tim Buschtoens

2013-06-07 05:41:01 EDT

Reproduceable with Controls demo:

1. Open Controls demo tab "ProgressBar" in IE (tested in 10) and any other browser
2. Start record the requests (F12->Network in IE)
3. Click "Start Background Progress".

In IE there are hundreds of requests until the process is finished, while in any other browser there are only a handful.

Comment 1 Ralf Sternberg

2013-06-07 06:51:16 EDT

The problem is that the responses are cached by IE. Other browsers don't seem to do that, but since the response does not explicitly prevent caching, that seems to be valid. Not sure when this issue was introduced, I think we've removed a "nocache" request parameter in 2.0.

A hot fix could be to add a "nocache" parameter again, but I think the proper fix was to set request headers as described in [1] to prevent the browser from caching:

response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
response.setHeader("Pragma", "no-cache"); // HTTP 1.0.
response.setDateHeader("Expires", 0); // Proxies.

The problem can affect custom service handlers as well. OTOH, caching might be desirable, e.g. for downloads. So it should be the responsibility of custom service handlers to set the appropriate headers.

I think we should set the headers in the ServerPushServiceHandler.

[1] http://stackoverflow.com/questions/49547/making-sure-a-web-page-is-not-cached-across-all-browsers

Comment 2 Ivan Furnadjiev

2013-06-07 07:22:32 EDT

(In reply to comment #1)
> A hot fix could be to add a "nocache" parameter again, but I think the proper
> fix was to set request headers as described in [1] to prevent the browser from
> caching:
> 
> response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); //
> HTTP 1.1.
> response.setHeader("Pragma", "no-cache"); // HTTP 1.0.
> response.setDateHeader("Expires", 0); // Proxies.
> I think we should set the headers in the ServerPushServiceHandler.
Completely agree with the proposed solution. Tested with IE10 and it works fine.

Comment 3 Tim Buschtoens

2013-06-07 07:24:45 EDT

Created attachment 232093 [details]
quickfix

This patch fixes this issue in the most simple manner possible by adding a no-cache parameter to the URL.

Tested in in IE8,IE10, current Firefox and Chrome. (Controls Demo+JavaScript tests). 
NOTE: I could not (yet) verify that it fixes the issue in IE8, since there is no built-in method to record network traffic.

Comment 4 Ivan Furnadjiev

2013-06-07 08:32:37 EDT

Created attachment 232095 [details]
Server-side solution

Set response headers mentioned in comment#1 in ServerPushServiceHandler.

Comment 5 Ivan Furnadjiev

2013-06-07 08:47:19 EDT

The above patch is tested with IE8, IE9, IE10, Firefox 21, Chrome 28 and Opera 12.15.

Comment 6 Tim Buschtoens

2013-06-07 09:21:33 EDT

Comment on attachment 232095 [details]
Server-side solution

+1
Also plays nice with IE7

Comment 7 Ralf Sternberg

2013-06-07 09:52:51 EDT

Comment on attachment 232095 [details]
Server-side solution

The patch looks good to me as well. I can't think of any risk coming from these additional response headers.

+1 for applying this last minute fix to RC4.

Comment 8 Ivan Furnadjiev

2013-06-07 10:19:57 EDT

Applied patch to master with commit 841491cf21e74013dc80b4e9180a7d0efa054d46 and to 2.1-maintenance branch with commit 8cf22a61806804af09e81f9ce15e3e3af81a3e15.

Comment 9 Ivan Furnadjiev

2013-06-14 10:35:07 EDT

Backported the fix to 2.0-maintenance branch with commit 383990cb4ae35adb18a4beabef9618a17aa26e15.