gehuangyi20 / jquery-stream Goto Github PK

If the padding is consisting of only html comment, the iframe transport cannot 
find documentElement of the iframe's content document until it receives not 
comment element likes text node or script elemment.

If the contents of an element ends with one or more newlines, IE ignores these 
in the innerText attribute. Therefore, if the server should decide to 
chunk/flush the output right after a newline and jquery-stream tries to parse 
this chunk, it will get confused.

Attached is a simple Perl CGI script which intentionally flushes a message 
right after a newline, along with a tiny HTML document that alert()s new 
messages. Try this in IE to see the problem. (I have only tested in IE 8, but i 
assume other version of IE have the same problem)

I have also attached a patch with a possible solution to the problem. This 
patch duplicates the element containing the data and adds one non-newline 
character to it before it reads its innerText. This way, the last characters in 
the innerText attribute is never a newline, and IE is happy. Only tested in IE 
8.

Let's play TDD!

When doing ajax for communicating with the server, custom headers will be used 
and metadata parameter will be removed in later version.

http://stackoverflow.com/questions/6453779/maintaining-session-by-rewriting-url

If XDomainRequest transport is used, URL will be rewritten to contain a session 
id acoording to the rule of each server-side technology.

closure-compiler, jetty-websocket and jetty-util

What steps will reproduce the problem?
1. run echo example under ubuntu linux and firefox 6.0


What is the expected output? What do you see instead?
websocket connection should be established, which is not the case.
running fine on chrome 14.
communication via post-request is possible but with firefox native ws-support 
ws should be used.


What version of the product are you using? On what operating system?
1.2


Please provide any additional information below.
maybe the new protocol version for websockets of firefox might be the reason? 
websockets are enabled under about:config

eventHandler.url() is a helper function which creates a URL containing extra 
parameters from 'openData' option and a timestamp parameter(_) for anti-caching.

If a stream closes, it is not able to reconnect.

Given that situation, $.stream(url) returns the already closed stream.

We need to support a way of reconnecting closed stream manually.

When I open a streaming connection in IE (using the hidden iframe transport), 
the first 6-8 messages are dropped entirely. 

Background:

My server is sending raw json data delimited by a custom string, i.e.

{"someInitialJsonData":["A","B","C"]}CUSTOM_DELIMITER{"someDataUpdate":4}CUSTOM_
DELIMITER ... etc etc 

Firefox works fine - it displays the initial data payload, followed by realtime 
updates. However, i.e. misses the initial payload. 

I am requesting the data using the standard $.stream() method, overriding the 
handleOpen/handleMessage for my custom stream.

I've tracked this down to the code snippet below (line 585 in version 1.2). 
When I enter this block, the response variable correctly contains all the 
initial messages. However, after the manipulation of the cdoc head, the 
innerText of cdoc.body.lastChild is blank, and when response is re-assigned, 
the data vanishes.

To solve this, I've implemented the following fix, which saves the response in 
a separate variable, and then re-injects it into the cdoc body. Can you please 
advise whether this fix has any unintended consequences, and consider merging 
it into the next release?

// To support text/html content type
if (!$.nodeName(response, "pre")) {
        // etc etc...               
    head.insertBefore(script, head.firstChild);
    head.removeChild(script);

    // save the reponse!
    var originalResponse = response;
    // The plaintext element will be the response container
    response = cdoc.body.lastChild;
    // re-append the data so it is not lost....
    response.appendChild(cdoc.createTextNode( originalResponse.data));
}

What steps will reproduce the problem?
1. Try to stream data in a custom fashion using the $.stream() api method and 
overriding the handleOpen/handleMessage methods in IE7


What is the expected output? What do you see instead?
I should receive all data received by the server. Instead, the first 6-8 
messages are dropped.

What version of the product are you using? On what operating system?

jQuery Version 1.2 with jQuery 1.7.1 on WindowsXP with IE7.


Please provide any additional information below.

This patch changes the code to accept alternative response formats:
 * alternative message separator
 * disable message length field

e.g.
      $.stream("...", {
           messageLength: false,
           messageSeparator: "\n\n",
      });

accepts a response format with no message length field. Messages are separated 
by an empty line:

<message1>

<message2>

...

I still got the throbber with chrome / safari : 

the online way to get around that was to wrap $.steam into $(window).load()

$(window).load(function () {
 setTimeout($.icescrum.listenServer, 500);
});

listenServer:function(){
    stuff to initiate stream;
}

What steps will reproduce the problem?
1. (try) open the stream.
2. (try) close the stream(.close or .handleClose(...))
3. .send() some data.

What is the expected output? What do you see instead?
this.dataQueue is "undefined". you check "if (this.readyState === 0)" but you 
set the readyState to 3 on disconnection. You should implement an readyState=3 
check and throw an $.error "stream is closed".

What version of the product are you using? On what operating system?
1.2

Please provide any additional information below.
an "undefined.push" - excpetion, if you don't check this, is not the better 
solution ;)

New feature-request

The idea is to be able to apply extra parameters to the initialization GET 
request. If these are static they could just be put into the given URL, but if 
they need to be updated (fx. on re-initialization) they need to be variable.

The default options object is extended with a default empty "openData" object.

The prepareURL function is then extended to run through the openData object and 
analyze it's property each property is added to the initialization URL. If a 
property is a function the value of the property will be the result of calling 
the function.

I havent checked out the code from the repository, so I'm not able to make a 
patch. I'll just copy the rewritten prepareURL function in here:

    function prepareURL(url, options) {
        var rts = /([?&]_=)[^&]*/;

        var params = {};
        for(var i in options) {
            if (jQuery.isFunction(options[i])) {
                params[i] = options[i].call(this);
            } else {
                params[i] = options[i];
            }
        }
        // Attaches a time stamp
        return (rts.test(url) ? url : (url + (/\?/.test(url) ? "&" : "?") + "_="))
        .replace(rts, "$1" + new Date().getTime())+"&"+jQuery.param(params);
    }

Then each call to this function need an extra paramter:
prepareURL(this.url, this.options.openData);

They can be used for a transport receiving only finished message like 
long-polling.

unable to custom the http request header.
i can not add my Authorization process for example.

By using this, you can override the default one and use various comet 
techniques such as long polling, server sent events, old hidden iframe while 
keeping the same API.

$.stream.socket handles custom socket or override existing one. The socket is 
in charge of two-way communication.

What steps will reproduce the problem?
1. use iframe/htmlfile on IE6-9
2. terminate the connection on server side(not client side)
(3. sending bad data can(could?) occur this problem, too. For example, if the 
server sends an html-page instad of the data-stream.)

What is the expected output? What do you see instead?
normally, you should be correct disconnected and can an auto 
reconnect(reconnect=true) or an manual reconnect.

But its impossible to reconnect. the cdoc.readystate stays on "interactive" and 
you are for every in your interate-loop. Even manual executecommand("stop") 
does not work. (testet in debugger). An manual .close does not work, too. But 
this works: call .handleClose(...).

My work arround is at the moment, if the server does not respond(normally, i 
receive every second a message), than i call .handleClose(true), .close() and 
reopen the stream. This works.

What version of the product are you using? On what operating system?
the newest, official release.

Please provide any additional information below.

You should deliver an forced-disconnect-method, for example .abort() and 
destroy the url-instance. I think it's important, too, to destroy the instance, 
mabye the object-instance could be go corrupt.

I'm using your stream-component in an realtime game. I have no problems to 
donate you, if you want.

I've misunderstood about functional inheritance so far.

A WebSocket Stream and HTTP Stream will share the same event handlers.

If a stream options can't meet requirements to establish a connection, for 
example a WebSocket stream with a browser not implementing WebSocket or a HTTP 
stream with undefined transport, an error will be thrown instead of returning 
base stream object.

When a message size is split into several chunks and transmitted sequentially 
in HTTP streaming, all but the last one will be ignored - although the chance 
is extremely low.

If the content type of the response is 'text/html', the Hidden iframe transport 
used by Internet Explorer by default understandably parses and executes it as 
tags, not as text. The other transports have no problem handling it.

At least the server-sent messages must be preserved.

Since ECMCA 5 its possible to use the strict mode by adding 

"use strict";

at the begining of the document.

See: http://ejohn.org/blog/ecmascript-5-strict-mode-json-and-more/

strict-mode is supported in Firefox 4 and in newest Google Chrome. strict-mode 
is backward compatible for old browsers, even for IE6, because it's only more 
stricter.

I have testet jquery.stream with strict-mode - no problems.

As you see in the title, very low priority.

What server is recommended for this plugin?

What is the server load like?

For example, is nginx a good choice or is there extra modules needed on the 
server end that would be an absolute must. 

handleOpen and handleMessage are low-level handlers that can directly deal with 
the server's response.

You can entirely customize the format of the server response by implementing 
them, and they can act as an adapter for the specific server-side technology.

In cases where you can not change the server implementation for some reason, 
this feature will be very useful. The minimum requirements is that the content 
type of the response have to be 'text/plain', but maybe you will be able to use 
'text/html' by properly controlling response.

Here's an improvement:
If you fire an event, you should always give the source(the stream, that's 
fireing the event) to the event-handler. (onmessage, onerror, onclose, ...).

If the source is delivered, there's no need to wrap something.

Greetings

The setTimeout interval being used in iterate function doesn't need to be 0. 
The increased interval will decrease CPU usage and ease the browser's burden.

This will affect XMLHttpRequest polling for Opera and Hidden Iframe.

Supporting streaming over WebSocket protocol by wrapping native WebSocket.

As in jQuery ajax module

A serialization type to be used for jQuery.param should follow the value of the 
jQuery.ajaxSettings.traditional.

As from Opera 11.50, it doesn't throw an exception when accesing status 
property in LOADED state. There is no choice but to use jQuery.browser object 
to identify browser.

After disconnecting connection of XMLHttpRequest object by abort method, its 
status property return 0 as from Opera 11.50, and it seems to legal according 
to spec.

jQuery Stream will be compatible with jQuery 1.5+

Hello,

Could you add the capability to disable ajax post request before send and on 
close ? 

It could be usefull in some cases.

$.stream("stream", {
    type: "ws",
    dataType: "xml",
    message: function(event, stream) {
        // Never called
    }
});

The stream object throws an error when receiving XML data via WebSocket, 
because it is not possible to init MessageEvent with XML document as data 
attribute in some browsers.

Currently, it fails in Opera, Chrome and Safari and works in Firefox.

The Stream object will have no constructor such as jqXHR of jQuery ajax.

$.stream.transport handles custom transport or override existing one.

Returning false when readyState property becomes 4 in iterate function and 
declaring a variable 'polling' are unnecessary.

If for any reason the default response handler gets stuck in some error so that 
the parsing cannot proceed, the stream connection should be disconnected.

Calling each listener will be effective depending on the stream's state.

Of course, considering the WebSocket and the throbber of doom.

It's a pity, but this solution does not work on IE7.

I built the jar, deployed to tomcat and tried out the countdown example.

It works fine on Chrome and Firefox, but IE just show "close". It doesn't even 
open the connection.

However, I see you implement the hack "htmlfile" in order to make it work, but 
it doesn't. Have you tested it recently?

Am I doing anything wrong?

I'm not sure if this is or bug or even a serious issue, but the behavior I see 
seems not correct. 

I see this in my log:
11:26:49.752 [qtp1975214396-19] DEBUG n.t.wicket.filter.CacheFilter - Invoking 
cache filter for /raris/streamservlet
11:27:19.751 [qtp1975214396-21] DEBUG n.t.w.j.servlet.StreamServlet - client 
20b8380e-ca45-4369-a5db-e3004b6f8cbf timed out
11:27:19.752 [qtp1975214396-21] DEBUG n.t.w.j.servlet.StreamServlet - client 
20b8380e-ca45-4369-a5db-e3004b6f8cbf completed
11:27:19.769 [qtp1975214396-19] DEBUG n.t.wicket.filter.CacheFilter - Invoking 
cache filter for /raris/streamservlet

So at 11:26:49.752 the client made a GET request to the servlet, at 
11:27:19.751 the onTimeOut method of the AsyncListener is called. This seems 
correct, as it is 30 seconds after the get request. The next get request is 17 
milliseconds too late. 

The weird thing is, clients don't show this behavior all the time and I can't 
find a cause which triggers this. I've seen this behavior from Firefox, IE and 
Chome.

I'm using a servlet inspired on the chat servlet example, client settings are 
the following:

$.stream.setup({enableXDR: true});
$.stream("${url}", {
        dataType: "json",
        type:"http",
        message: function(event) {
                try {
                    streamLog(event.data.javascript, "debug");

                    eval(event.data.javascript);
                } catch(ex) {
                    streamLog(event.data.javascript, "debug");
                }
        },
        openData: {
            type: "json",
            clientid: "${clientid}"
        }
});

Whether to trigger global stream event handlers

First of all, thanks for this plug-in :) Working very nicely for us so far.

I am curious as to why I get POST errors when I send data to the stream. There 
are no actual problems at all - the data is being sent successfully - but the 
JS console is complaining with a simple POST error.

I also sometimes get "Failed to load resource" errors, even though nothing is 
wrong. Is there anything I can do to suppress these meaningless errors? Is it 
to do with the server side stuff?

Thanks

handleSend is a low-level handler that can manage all requests to be sent to 
the server. You can manipulate ajax options to be passed to jQuery.ajax(). It 
requires jQuery 1.5 for enhanced Ajax interaction.

What steps will reproduce the problem?
1. use IE (for example 9)
2. send one LARGE message (for example 100,000 chars).

you choose the htmlfile transport. If you send small messages, no problem. of 
you send than a really big message, the following occurs:

(not sure,if directly, i have debugged some loops later)
response.innerText is empty and....stays empty. But the IE develper toolbar 
shows me, that the downloaded text is growing.

you are in the interate-loop, response.innerText never unequals '' ----> hang.

Sebastian.
Greetings from Germany

What steps will reproduce the problem?
1. use chrome or opera and set type to 'http'
if have debuged and found out:

message.size is NaN afeter first loop, but you check if message.size == null 
and you go never into the 'IF'. How ever, i have reimplemented your complete 
handleMessage-function in a (maybe?) more reobust way.

the next problem was, sometimes, if the server quits the connection and the 
client makes no reconnect but you refresh the page with F5, sometimes, the new 
page becomes an old chung of data, can't explain that. so i have optimized the 
function to handle messages in other way.

mesasge format:
#3        abc
#12       abcdefghijkl
#15       abcdefghijklsdfsdfsdf

between # and the data begin are always 10 chars, doent matter how much the 
size of the size is.

on server side and client side, i escape the '#' to an custom format.

function body:

var sizeBegin = text.indexOf('#', message.index);
var sizeSize = 10;

if (sizeBegin < 0) return false;

if (message.size == null && text.length - sizeBegin >= sizeSize + 1) {
  var sizeStr = $.trim(text.substr(sizeBegin + 1, sizeSize));
  message.size = +sizeStr;
}

var dataBegin = (1 + sizeBegin + sizeSize);
if (text.length - dataBegin >= message.size) {
  message.data = text.substr(dataBegin, message.size);
  message.index = dataBegin + message.size;

  // Completes parsing
  delete message.size;

  return true;
}
else {
  return false;
}

First: thank you for this great piece of software. 

I tested your plugin yesterday with jetty 8 M3 and your echo server example 
under ubuntu 11.04 and did not have any problems by using google chrome.
But with firefox 5 I was unable to connect to the websocket, although having 
websocket enabled under the firefox settings.

On the other hand the jetty websocket example distributed with the eclipse wtp 
plugin runs fine with websocket on both browsers, chrome and firefox. Thus, 
websocket for firefox seems to work well but not with your plugin.

Streaming over http works fine on firefox but I would like to use websockets 
for my next project.

Any ideas?