Repeating message template observed in subscriber curl test

[whhayes]

I have configured a nginx server with ngix-push-stream-module, SSL, SPDY, fastcgi, and modsecurity. I am using fastcgi with a mono server. Up to this point SSL, SPDY, and fastcgi tests are working well. For ngix-push-stream-module, I have all locations pointing to directories (/pub, /lp, /sub, etc.) on the mono-server. For DNS name of this server we are using a cname and not the hosting service's vps FQDN.

I used the nginx.conf file at this site as the basis for my nginx.conf and sites-available/default confgurations.

When I attempt a curl command for for ssl such as

curl -k --no-buffer 'https://localhost/sub/ch1'

or

curl -k --no-buffer 'https://The server's cname/sub/ch1

I see the following response:

p(-1,'',' ','', 'Thu, 01 Jan 1970 00:00:00 GMT', '0');p(-1,'',' ','', 'Thu, 01 Jan 1970 00:00:00 GMT', '0');p(-1,'',' ','', 'Thu, 01 Jan 1970 00:00:00 GMT', '0');^C Publish and Channels-Stats ALL seem to work normally, I think. Channel-Stats ALL returns: {"hostname": (fqdn of hosting service vps and NOT cname of web server), "time": "2014-04-21T01:12 :56", "channels": "0", "wildcard_channels": "0", "uptime": "83712", "infos": [ ]} Requests for Channel-Stats?ch1 returns a 404 error, which since it doesn't exist, I believe is the expected results. Publish for ch1 returns: {"channel": "ch1", "published_messages": "1", "stored_messages": "1", "subscribe rs": "0"} I can only think my configuration is wrong. Could you suggest where I might start looking? Publish for ch1 returns:

[wandenberg]

I did not understand your problem. The isn't the message template being repeated, it is the ping message applied to your message template, take a look on the -1 id.

If I misunderstood your problem, sorry. Try to explain in a clear way, and show the configuration you are trying to use.

Regards

[whhayes]

Thank you very much for your very quick reply. I will test again tonight after work and include my nginx.conf and sites-available/default configuration files. I am new to nginx and mono, but I have been trying to solve problems on my own. I am learning a lot.

May problem I am not seeing a published message in the subscriber channel. In the curl tests, when I saw the subscriber repeating message templates I thought something was wrong and hit CTRL-C. I will test again tonight with curl and this time not hit CRTL-C.

Earlier I had tried to use the example long-polling client HTML page, I placed the long-polling client HTML page in the root of my web server and the pushstream.js file in the /js folder, I was not able to see a published message in client PC's Firefox browser session. Using curl I published a message to ch1 and did not seen anything in the client web page's window area. Does the long-polling client HTML page need to be in the /lp directory instead? Are there any changes to the long-polling client HTML page that have to be done before it can receive a message?

[whhayes]

Thank you very much for your very quick reply. I will test again tonight after work and include my nginx.conf and sites-available/default configuration files. I am new to nginx and mono, but I have been trying to solve problems on my own. I am learning a lot.

My problem I am not seeing a published message in the subscriber channel. In the curl tests, when I saw the subscriber repeating message templates I thought something was wrong and hit CTRL-C. I will test again tonight with curl and this time not hit CRTL-C.

Earlier I had tried to use the example long-polling client HTML page, I placed the long-polling client HTML page in the root of my web server and the pushstream.js file in the /js folder, I was not able to see a published message in client PC's Firefox browser session. Using curl I published a message to ch1 and did not seen anything in the client web page's window area. Does the long-polling client HTML page need to be in the /lp directory instead? Are there any changes to the long-polling client HTML page that have to be done before it can receive a message?

[wandenberg]

The html can be on any location, and must not be on /lp location :) Locations with push_stream_subscriber or push_stream_publisher directives will not work to return files. Did you used this example https://github.com/wandenberg/nginx-push-stream-module/blob/master/docs/examples/long_polling.textile#long-polling- ? The changes on the client html example depends on what you did on your configuration, usually you don't need to do changes.

[whhayes]

Thank you for the clarifications. I was able to send and receive messages via curl. I will test out the long polling html web page tomorrow evening. No changes were necessary for the nginx.conf or sites-available/default configuration files.

[whhayes]

I used the long polling example page running under SSL. It appears to be a mixed mode issue with the Firefox console returning a "blocked mix-mode" error.

Blocked loading mixed active content "http://(my server name)/lp/ch1?&tag=&time=&eventid=&_=1398214014205" [Learn More]

The console also had 242 pushstream.js as the possible flaw. I assumed this was line 242. I could not immediately see what was going on.

It looks like pushstream.js does try to determine if SSL is being used. I'm not exactly sure what I will have to patch. I do not anticipate running anything other than SSL.

[wandenberg]

If you want to serve your html using https is better to serve the content using https too. To do this add the useSSL: true option on the js code, when creating the PushStream object like this:

    var pushstream = new PushStream({
      host: window.location.hostname,
      port: window.location.port,
      modes: "longpolling",
      useSSL: true
    });

this should fix the issue.

[whhayes]

On 4/22/2014 8:50 PM, Wandenberg Peixoto wrote:

If you want to serve your html using https is better to serve the content using https too. To do this add the useSSL: true option on the js code, when creating the PushStream object like this:

var pushstream = new PushStream({ host: window.location.hostname, port: window.location.port, modes: "longpolling", useSSL: true });

this should fix the issue.

— Reply to this email directly or view it on GitHub https://github.com/wandenberg/nginx-push-stream-module/issues/140#issuecomment-41116658.

Thank you very much!

[whhayes]

Should this new pushstream object you've described go around line 880 of pushstream.js?

[wandenberg]

No. Do not change the pushstream.js Put the code on your html. You will see where when you edit your html copied from the long polling example ;)

[whhayes]

Missed it somehow on the first read-through. Thank you very much! it is now working. :-)