We Keep Coding

Tomcat websocket code succeeds on localhost but fails when hosted and modified for remote host

This has been discussed before, but never successfully (as far as I can tell) resolved. I'm using Tomcat 9, eclipse, and of course Java and Javascript.
Chapter 1
I can make work neither the well-written javaCodeGeeks websocket example, or for the purposes of providing a minimal framework, re-hosting the Tomcat example chat/echo code outside of their magic realm. (I'll have more to say about this below.)
I've also been poring over the Tomcat logs and scrutinizing the GET requests which return 404 errors and mystery 7xx error codes, some of which I've been able to infer. (There is no general documentation of the 7xx codes.) I'll discuss those at the bottom.
So the nub of the issue is that Websocket code works end-to-end when hosted by Tomcat on localhost, but when hosted on a remote host, the connection created by "new WebSocket" fails. (This issue has been discussed several times, in multiple forums, but it seems more likely that the questioners have given up rather than succeeded and moved on.)
So I would like to know two things. First, how to make my example code work when hosted remotely (any port in a storm) and second, I would like to know how the tomcat examples work at all. The sample I've concocted is not something new and suspect; it is simply the chat annotation from the Tomcat examples. (There are a few reductions so that it works in a minimal environment, and those are noted. In particular the logging routines, and a parse-html class was pulled from its home on Tomcat.)
The result of this sample when executed against a remote server is a 404 error (with some curious 7xx error codes, which I observe and report on below).
If you want to cut to the code, here is a link to a war file that includes sources; They are just adopted from the Tomcat sample chat server to run in a minimum configuration. Three files, 2 java and one index.html. You can run/deploy it directly on tomcat in webapps or pull the sources into eclipse to compare and edit.
SampleCode
Dossier
https://1drv.ms/u/s!AqbqlA2vzkjRcrGjW8rDRLW3o50?e=fgeh0U
Here is the point:
var target;
// Shows the bug: unless location resolves to local host won't work
target = 'ws://' + window.location.host +
'/SocketBugMinimum/websocket/chat';
//
// For testing purposes,
// access the tomcat one in the magic directory, not this one...
//target = 'ws://' + window.location.host +
// '/examples/websocket/chat';
// also try:
// examples/websocket/echoStreamAnnotation
// it will work too...
And when it goes behind the curtain
Chat.socket = new WebSocket(target);
it returns with the error on the console:
WebSocket connection to ws:REMOTEHOST:8080/SocketBugMinimum/websocket/chat failed: Error during WebSocket handshake: Unexpected response code: 404
Now a couple of things to note.
1. Works fine when host is localhost.
2. You can connect to remote host accessing the Tomcat examples websocket, even though they have nothing to do with this code. This is both fun and instructive.
3. This works even when you are yourself hosted on localhost.
The SocketBugMinimun app produces the same result run from eclipse, accessing localhost or remotehost from either chrome or firefox, and from the tomcat html-manager (i.e. host...8080:/Manager/html).
Now looking through the Tomcat logfile (grep the ones with today's date for GET to see all the connect activity) you will find an interesting numeric code beside the reported 404 error.
As I promised above, I've tried to infer meanings of some of the 7xx codes produced in the logfile; they seem to modify the 404 error. (7xx codes are not part of HTTP as reported in an RFC; they seem to be recycled and augmented Modem codes, of all things.) If anyone has a better understanding, please share it. Tomcat-developer endorsed description of these codes it would be great to know. apparently tomcat websockets busily produce different and rich errors, but there is just no way to know what they are. (I've scoured the tomcat docs, and Google finds nothing.) In order of usefulness:
727 Listener exists but terminal endpoint is bad
733 Endpoint exists and is hunky dory but I won't let you connect to it because I'm mean
719 No root element
746 Valid root, but the rest of the path is bad
726 You tried /a/b but you need /a/b/c
737 Beats me
748 No idea
Chapter 2
Now the mystery to me is how the Tomcat examples work at all.
It appears that by being hosted in the examples directly they seem to have conferred on them some magical powers to use sockets. I've tried to reproduce those results using catalina privileges but am unsuccessful. (And if you are a connoisseur of Tomcat privileges you will note that the sample files says "this is what you should do to generate these effects" but those lines are COMMENTED OUT and the examples work anyway!)
I also experimented with Valves, but have nothing useful to report. If it wouldn't kill the Tomcat people to provide a few more documented examples, it would be helpful.
There is also a voodoo file in Tomcat called servers.json (you will note that no other files with a .json extension are shipped with the product). This file and its curious and undocument incantations change the names of the network pathname to the endpoints. (This file is why I chose to repro this with chat, which uses no other magic, rather than echo.)
One likely solution might be that the examples are conferred special powers in catalina.policy. But no dice. I tried to add WebSocket privs, and it doesn't do any good. Here is the diff between the original and what I added.
// ++
< // everyone needs sockets!
< grant {
< permission java.net.SocketPermission "*:8080", "accept,connect,listen,resolve";
< };
<
< // Granting permission for Spades to be reached via websocket
< grant codeBase "war:file:${catalina.base}/webapps/Spades.war*/-" {
< permission java.net.SocketPermission "*:8080", "accept,connect,listen,resolve";
< permission java.lang.RuntimePermission "accessClassInPackage.org.apache.tomcat.websocket";
< permission java.lang.RuntimePermission "accessClassInPackage.org.apache.tomcat.websocket.server";
< permission java.sercurity.AllPermission;
< };
< //--
<
275c260
< // };
As I said, it didn't seem to do any good. Same sad errors in the logfiles.
Thanks in advance for your help.
Marklan

Problem solved.
I did some more snooping around and learned that there are discrepancies in Tomcat results when you are running older versions of Java. Coderanch had this helpful article:
https://coderanch.com/t/659638/application-servers/WebSocket-deploying-Server
I checked and realized I had Java 1.8 on my server. (Dooh!)
Thanks to ServerWorld for its helpful site, here is helpful information on upgrading Java, finding the version you need, etc. Here is a link to the English version, from there you can select OS config, etc.
https://www.server-world.info/en/
So, I upgraded to version 11 JDK (i.e. downloading jdk-11.0.1_linux-x64_bin.rpm from oracle.com) running rpm to install, i.e. from the download directory
rpm -Uvh jdk-11*
to install.
Finally configuring away from the old version without deleting it (in case this doesn't work!)
alternatives --config java
to select and install the latest. Restarted Tomcat and it all worked.
Thanks to the people who looked at this with me, and scratched their heads. I appreciated the efforts.
Happy coding. Hopefully this mis-adventure can be helpful to anyone else who has the same problem.
And it would sure be nice if the Tomcat team could document the 7xx errors. I have no idea why the older versions of Java did not work. I can't imagine how something like this would be version dependent, but I guess my imagination is just not that good...
I did find some other useful stuff that I want to share. In particular the magic cookie that makes the examples files work is buried in a call to ServerApplicationConfig, wheich essentially exports and deploys the endpoints in subdirectories. Check out the file ExamplesConfig.java buried off in webapps/WEB-INF/classes/websocket. It takes advantage of a Tomcat hook that scans your subdirectories for you, and exports endpoints, or declines to export them as you wish.
M

Can't retrieve a valid WinSAT assessment. javascript console

i frequently get this error when running my web app on google chrome
[2536:2008:0502/143602:ERROR:gpu_info_collector_win.cc(96)] Can't retrieve a valid WinSAT assessment.
its ok in firefox and IE..
i've already search for solutions but with no luck.
i am using Aptana Studio + Sencha
how to get rid of this?

I had this error when I was providing the path to chrome.exe as the system property - it went away when I was using chromedriver.exe as downloaded from here: https://code.google.com/p/chromedriver/downloads/list

This means that winsat validation failed.
Winsat is a tool that checks out windows. If it fails, normally this indicates that something is wrong with your system (probably a driver).
In the above case, I would go with the display adapter driver, so try to update it via the Windows Update.
To run winsat yourself, you can run 'winsat formal' from the command line. Then you can look for suspicious output (if you have 0 F/S performance in the direct3d, then this is not fine :-))
Based on the problematic output, you can see what is wrong in the system (in the above example, the display adapter was found as a standard VGA, and a simple update, fixed the error made chrome/selenium).
HTH

Javascript error when sending XMLHttpRequest in IE7

I have a bit of a strange problem. For one of my clients I've added some ajax functionality to their website. To get the context; it's a website for a travelagency and pricetables are generates by ajax-calls to reduce serverload and improve user experience.
Only now I received an email where they say it is not working in IE7. So, to test this I first installed IETester but this almost crashes every single time I only open a website. So I've downloaded a trialversion VMWare Workstation and installed a virtual XP machine with IE7 (because IE8 is on my primary Win7 install). What a hassle to simulate an error eh?! ;)
Anyway. After some debugging I think it's the xmlHttpRequest status property, when I try to alert this status in the corresponding javascript function IE shows an exclamationsign at the leftbottom corner with some vague 'not further defined error' message while in IE8, FireFox and Chrome this is no problem at all.
So I figured I might have been using the wrong XMLHttpRequest object. But then again, the first call which is also made to intiate the first pricetable for the closest month works just fine. Just to be sure I googled which object should work for IE7, now I'm using Msxml2.XMLHTTP and the initial load goes well.
When I click an <a onclick="callToFunction(with, correct, params)">click</a> it gets into the function to update a <div> but then it sort of freezes. I found out that the xmlHttp.readyState is 4 but I can't output the xmlHttp.status, then the 'not further defined error' message shows again at the leftbottom corner.
My question after a bit of a long evening trying to solve this, do you guys have any clue what might be the problem?
Example:
http://www.bergenmeer.nl/50/oostenrijk/tirol/gerlos/residence-zillertal.html
Click tab 'Prijzen en aanbiedingen' (Prices and special offers) then click another month in the bar below, e.g. jan, feb, maa.
Note, the disfunctioning only appears in IE7.

In IE7 you could try using native window.XMLHttpRequest.
For what it's worth, I once had an issue which was resolved by removing xmlhttp.setRequestHeader("Connection", "close"); (which I did not see in your code...)

IE6 Javascript problems with $Revision$ in the filename

We recently started using SVN Keywords to automatically append the current revision number to all our <script src="..."> includes (so it looks like this: <script language="javascript" src="some/javascript.js?v=$Revision: 1234 $"> </script>). This way each time we push a new copy of the code to production, user caches won't cause users to still be using old script revisions.
It works great, except for IE6. For some reason, IE6 sporadically acts as though some of those files didn't exist. We may get weird error statements like "Unterminated String Literal on line 1234," but if you try to attach a debugger process to it, it won't halt on this line (if you say "Yes" to the debugger prompt, nothing happens, and page execution continues). A log entry for it shows up in IIS logs, indicating the user is definitely receiving the file (status code 200, with the appropriate amount of bytes transferred).
It also only seems to happen when the pages are served over https, not over standard http. To further compound things, it doesn't necessarily happen all the time; you might refresh a page 5 times and everything works, then you might refresh it 20 more times and it fails every time. For most users it seems to always work or else to always fail. It is even unpredictable when you have multiple users in a corporate environment whose security and cache settings are forcibly identical.
Any thoughts or suggestions would be greatly appreciated, this has been driving me crazy for weeks.

Check your log with fiddler2 to make sure the browser request the page, and do not use the cache instead. Also check the URL of the JS script and the header returned.
Are you using GZip? There has been issues reported with it.
I would suggest testing using Internet Explorer Application Compatibility VPC Image. That way, you can do your tests with a 100% IE6, and not one of those plugin that claims to simulate IE6 inside another browser.

I think this is a very clever idea. However, I think the issue could be related to the spaces in the url. Technically, the url should have the spaces encoded.
See if you can customize the keywords in SVN to generate a revision number without special characters.

Output the rendered contents of a page on a JavaScript error

I'm having problems with getting decent JavaScript error invormation in a Production environment.
When I'm developing I can just attach a debugger and (usually) fix the problem.
When I get the same error in a production environment however at best I see is an error report that looks like this:
Error: Object doesn't support this property or method
Url: SomePage
Line: 42
Char: 13
Which doesn't help me very much - I can't see the rendered page and so I have no idea what line 42 looks like.
Is there any way for me to log the entire rendered page contents whenever an error like this occurs? (So line 42 of the output is the line where the error occured)
While I'm at it, are there any other techniques that I can use to help with getting useful error information from JavaScript (without need to break into the debugger) - failing that is there any way that I can structure my JavaScript slightly differently to help getting decent debug information?
I'm predominantly interested in IE - this is the browser that tends to cause me most problems.

I don't think you'll be able to get the exact original HTML source of the page back in all pages and all browsers.
Regarding debugging, you could use a logging library such as log4javascript (disclaimer: I wrote it) and intersperse logging calls in your code. log4javascript enables you to send logging messages back to the server via Ajax.

Unfortunately, IE has by default the most utterly useless error reporting. The script and line number reported in the error are essentially guaranteed to be absolutely wrong. You can, however, install the IE developer tool bar (for IE7 and older, it's built into IE8) from Microsoft, which can help track down the error source.