By convention and by defaults in the usual config files/settings, web servers listen to port tcp/80 for HTTP and port tcp/443 for HTTPS. However, they may accept incoming requests on any other TCP port, if configured accordingly.
Also: for convenience, most http client side libraries (or browsers) omit the
:80 if the protocol designator is
http:// and the
:443 if it is
However, when handling the user's request in the background, they'll assume the given default values when they compose a connection request and hand it down the to the TCP layer. After all, the TCP layer in itself has no clue about which destination port to connect to, unless it gets complete instructions.
HTTP has no concept of an "application port" (like the example of the 4200 you give) that would need to be associated with a given TCP port. On the server (or reverse proxy) side, one could generate clever directories or ("virtual") paths, to make the URL look like http://servername.com:80/applications/app4200/index.html - but that would remain entirely unrelated to the concept of a "port" at Layer 4.
... which brings me back to: Server side configurations are actually quite off-topic in Network Engineering. Serverfault might be a better place if you want to dive deeper into this topic.