Tim Holloway

Afterthought.

The reason we call it the "Internet" is that unlike earlier ttimes when computers were centralized and networks only connected terminals within their local net, the Internet connects many networks together. Do a "traceroute" even to another local server and likely it will list a half-dozen or more intermediate nodes. Just think of what would happen if backbone nodes had to lock down their ports for continuous-connection services.

Oh yes, and I forgot. PCs mostly use bytewise-discontinous memory organization. IBM mainframes, Motorola CPUs and various other systems are bytewise-continous. A text -based protocol doesn't have to deal with "endian" problems. Binary prototocols, on the other hand…

There are 2 ways to handle communications between a client and server. One is the continuous-connection method used by traditional time-sharing systems such as IBM's TSO.

The other is request/response. Well, actually there's a third, which is permanent connection, but I don't think you want to surf the Internet with that.

The problem with continuous connection is that it locks down a pair of TCP ports for as long as the connection exists. We have a lot more available ports these days, but I don't think that you could run Amazon.com with only 65535 connections per server machine (less overhead such as ports for DNS, DHCP, and so forth).

The request/reply model is a lighter-weight protocol where you only need to lock down ports between time of request and end of reply. A similar model was used on, for example, IBM's CICS, where again, resources were not continuously available, but only on demand. CICS predated TCP and used hard-wired or dial-up sessions, but the general architecture was more similar to HTTP than to TSO.

Because ports are not locked down for long periods, the number of possible clients is much larger when using HTTP.

HTTP also carries one very useful attribute that was common back in the early Internet days. It's text-based. If you need to test an HTTP server or SMTP mailserver, you can use telnet to brute-force conversations and ensure that the infrastructure is all in place and operational. Perhaps more importantly, with the aid of simple code page translation an EBCDIC-based IBM (non-PC!) computer can carry on conversations with machines running under ASCII.

Not every application needs full 2-way synchronous communication. And if I understand the Web Services protocol correctly, it's more overhead than running a single continous 2-way channel.

Having a separate binary API for everything we do would be a nightmare. Remember CORBA? Who uses Java's own RMI? Well I have, but not over the Internet.

As a general rule every Internet protocol has one or more standard ports. To be secure on the open Internet, we firewall as much as possible and often perform deep packet inspection. So having a different port for each API (a là CORBA) and programming a site's allowable rules for each API would be very expensive.

We passed the need/desire for ultra-high efficiency in computing somewhere between the time when a mainframe computer ran $10 million or more and people's wrist-watches exceeded said mainframes in processing speed and even RAM. On the one hand I hate it because it has made "Git 'er Dun!" the rule of the day and if it crashes, you just tell people to "turn it off and bacl on again". On the other hand, the complexity of modern-day systems has reached a level where a custom low-level API for every service is not considered tenable.

I should note that while ostensibly primitive, HTTP support over the years has received a number of invisible performance enhancements. The overhead of opening/closing a port for each HTTP request was reduced by transparent "keep-alive" functionality. Client and server wil often negotiate for overhead-reducting functions such as transparent pver-the-wire data compression.

Finally, it should be noted that the primary protocols for the Internet are defined in the RFCs and one of the things an RFC tries to do is define a protocol to be powerful, but simple. As with Unix philosophy of taking many small programs and linking them together in place of one enormous TRON-style Master Control Program, Because you never know what direction may prove to be then Next Big Thing.

Himai Minh wrote:With regard to "using POST as Get", POST is non idempotent while GET is idempotent.
That means calling GET multiple times return the same result.
But calling POST multiple times will end up creating multiple resources.

In theory. As I said, those verbs are often used in ways that defy the original intents.

GET wouldn't be impotent if it was used to obtain a display that updates in real time, for example.

Stephan van Hulst wrote:Sorry, what I meant to say is that it is not secure to send sensitive data with a GET request, regardless of whether the request itself is encrypted.

GET requests don't have a body that is kept confidential. You can only put data in the URL and in request headers, and those have a nasty tendency to end up in browser caches and server access logs.

I'll accept that. It's less of a security risk, since the plain-text URLs are only visible at the endpoints, and not in transmission, but the more places plain text is hanging around, the more opportunities for an invader to break in and slurp them up. Same reason why Java prefers to deal with passwords as character arrays (which can be blanked immediately after use) instead of Strings (which have to wait for garbage collection).

One of the reasons I like JavaServer Faces. All that stuff is readily available already as part of the JSF framework I use.

However, if you prefer the hard way, commonly one keeps the error block, but makes it hidden when there is no actual error.

Welcome to the Ranch, Miguel!

That's more code than my bleary eyes can digest, but my first suspicion would be that you're not defining the proper number of columns.

One clear danger signal is the "SELECT *". When you don't specifically indicate what coumns to pull from the database table, you're not guaranteed as to the number or order of volumns that you get back. So even if that part was valid today, someone could alter the database schema and make your app fail.

Stephan van Hulst wrote:... if the payload contains sensitive information, you want it protected by TLS. That is not possible with a GET request.

I'm not so sure about that. I'm fairly certain that an https GET is encrypted from the, er "get"-go. Actually targeting the server is a bit harder to protect, since you cannot route to a (possibly-resolved) IP address without the destination IP in the TCP packet, but the first thing that happens when you send a request to open a listening server port is that encryption is negotiated even before the URL itself (and its GET info) is transmitted.

However, GET was never intended to send large amounts of data, and originally GETs were limited to a fairly small length, often 1024 characters or less. POST was specifically designed for the purpose of larger payloads. POST is theoretically unlimited in payload size, although servers typically have a cutoff point in order to discourage DOS attacks and the like. Systems that receive large images, ZIP files, videos and the like may allow payload sizes in the megabyte range.

The original intent of GET wasn to request (GET) data from the server, perhaps aided by a few identifying/qualifyin parametes. The original intent of POST was to literally post data to the server. However, we have re-purposed these verbs to allow for things like AJAX, ReST, and the like and in some cases adopted conventions to allow a consistent verb usage across heterogeneous transfers within a given framework. We could have added new HTTP verbs for things like long data-in/long data-out and such, but instead we simply futz around.

So long and short of it, yes, I'd POST.

Too many "not" clauses in that last one. I actually like Jack's original better, although it's over-indented. That is, of course, assuming that the code does what's intended!

I once read something by a professor who said that "NOT" is so confusing that he actually scheduled a course specifically geared to dealing with negatives. I can well believe that, since for ages, IBM's mainframe job control language (JCL) would execute steps on the basis of "if this is NOT true then DO NOT execute". It took them decades to upgrade to being able to say it without the "nots".

I understand that having an empty "if" clause and doing the work in the "then" is disquieting, but it really is cleaner, despite that.

OK, by my reckoning, the framework classes include mb-3, input-group, input-group-text, form-floating and form-control.

So I'd check the docs on them to be sure you're using them right.

I'd also pop open your browser's debugging pane to see if there are any complaints as well as to see what the cumulative CSS properties applied to the elements are.

I didn't need the validation stuff - it doesn't affect the CSS layout. But unless my watering eyes deceive me, you still haven't shown the definitions of the CSS classes used by the problem code.

Also, it doesn't matter if you define your source code as HTML5 or HTML4. If the client's BROWSER doesn't support HTML5, then the HTML5-specific stuff won't work right.

It would have been helpful if you'd posted the source for the classes that you referenced in that form.

However,  a couple of things to check. First, since I don't see an actual <form> I'm assuming that you just snipped out the immediate section, If you didn't have a form tag wrapping that stuff, then all bets are off, since you cannot validly have input controls that aren't inside a form.

Secondly, I believe that you're using HTML5. If your browser doesn't support HTML5 (most newer ones should, however), then it could possibly mess up that way, since HTML's way of dealing with tags it doesn't understand (like HTML5 tags in an HTML4 browser) is to ignore the tags and output the tag body text (if any), verbatim.

One of the very first things I learned on-the-job in IT is that it's usually not a good idea to create keys at the same time you're loading tables. Since keys are often kept in some sort of balanced tree, the continual re-balancing that comes from seeing a stream of keys come in en masse can really slow down the loading.

Although in your case, I think key creation failed outright.

If you didn't delete the previous load before running again, then the key creation process probably had existing data to work on, and it's a lot more efficient to build a keyset from a loaded table.

This is just a rough guess and there almost certainly have been some error messages that should have come out of the load, but as long as you got your import done properly, it's not important.

OK, I think you got 2 different items confused.

First, the war-tracker. It turns out that Tomcat adds this file to an exploded WAR so that it can detect changes made to that WAR while Tomcat was not running:

https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/config/host.html

There was a bug detected in 2016, reported and fixed, per your bug URL. As long as you're running a version of Tomcat newer than the versions listed in that bug report, that shouldn't be a problem. The problem was indicated in the change log, but as a repaired problem. The change log appears in a separate webapp named "docs", and offhand, I'd think that the docs app came with your copy of Tomcat, but you should be able to delete it safely (and it's one less security weakness if you do).

I said that applications should never update a deployed WAR, but of course, Tomcat can do whatever it likes. Note, however, that this feature is only applicable if Tomcat has an exploded WAR. Though since that's the default, it would be doing so.

Your second concern comes from the fact that the webapp is deployed under the context path "/AwardTracker_NJE/". The award tracker app has no direct connection or knowledge of what Tomcat's trying to do with "war-tracker", the similarity between names is purely incidental. The "404" errors you see in the log indicate an unresolvable URL, and that's just what happens when an improper URL is passed to a webapp, either badly capitalized/spelled, or because a component of the application didn't get installed.

Welcome to the Ranch, R.S.!

Dialogs generally don't have a GUI parent (as opposed to a logical parent) because that would constrain them to always fit inside their parent window. Likewise, maximize/minimize isn't common, since when a dialog is presented, it is expected to be the most important thing on the screen.

A Modal Dialog blocks all messages to the rest of the app. A Modeless Dialog is more interactive, such as showing progress of an app process, but Swing isn't as concerned with modal/modeless as some systems are. A modeless dialog equivalent is probably best presented in a child frame window, in which case the resizing gadgets come for free.

Hmmm. There are too many Tomcats in that directory display. If "Tomcat_nje" exists but does not display, then I suspect one of two things:

A. The userid that Tomcat is running under has rights to see it, but the desktop user does not.

OR

B. There's a soft-link (alias) for Tomcat_nje and it's messed up somehow.